Guida alla gestione dei dispositivi di rete: SNMP, TFTP e syslog senza un NMS completo

La gestione di switch e router senza software costosi si affida a tre protocolli leggeri. La combinazione di polling SNMP su porta UDP 161, trasferimenti di file TFTP ai sensi della RFC 1350 e raccolta syslog sulla porta UDP 514 offre visibilità e ripristino completi. L'esecuzione di queste operazioni da un'unica utility copre le attività quotidiane senza il sovraccarico di una grande piattaforma.

Cosa fanno concretamente SNMP, TFTP e syslog per te?

Ogni protocollo risponde a una domanda diversa su un dispositivo. Insieme coprono la maggior parte di ciò che fai su uno switch o un router tra un'installazione e l'altra.

SNMP risponde a "in quale stato si trova questo dispositivo in questo momento?" Il Simple Network Management Protocol (SNMP) consente a un manager di leggere i valori da un dispositivo. Una richiesta get legge un singolo valore, come il tempo di attività o il conteggio degli errori di un'interfaccia. Un walk legge ogni valore sotto un ramo dell'albero, uno dopo l'altro. Ogni valore ha un identificatore di oggetto (OID), un numero separato da punti come 1.3.6.1.2.1.1.3 per sysUpTime. Una Management Information Base (MIB) è il file di testo che assegna a quei numeri nomi leggibili dall'uomo.

TFTP risponde a "come faccio a trasferire un file da o verso questo dispositivo?" Il Trivial File Transfer Protocol (TFTP), definito nella RFC 1350, sposta i file sulla porta UDP 69 senza necessità di login. La maggior parte degli switch e dei router gestiti può copiare la propria configurazione corrente su un server TFTP. Possono anche scaricare immagini firmware da esso.

Syslog risponde a "cosa mi sta comunicando questo dispositivo?" I dispositivi inviano righe di log a un ricevitore man mano che si verificano gli eventi. Il formato attuale è RFC 5424, e molti apparati di rete inviano ancora il vecchio formato BSD descritto in RFC 3164. I trap SNMP svolgono lo stesso compito per gli avvisi strutturati. Un trap linkDown, ad esempio, arriva sulla porta UDP 162 nel momento esatto in cui una porta si interrompe.

Dove si colloca ciascun protocollo

Attività	Protocollo	Trasporto e porta	Standard	Sicurezza integrata
Interrogare lo stato del dispositivo su richiesta	SNMP get, getnext, getbulk	UDP 161	RFC 3416 (operazioni), da RFC 3411 a 3418 (SNMPv3)	v2c: community string in testo non crittografato. v3: autenticazione e crittografia (RFC 3414, RFC 3826)
Ricevere avvisi strutturati	SNMP trap o inform	UDP 162	RFC 3416	Corrisponde alla versione SNMP in uso
Eseguire il backup delle configurazioni, ripristinare le configurazioni, caricare il firmware	TFTP	UDP 69, poi una nuova porta per trasferimento	RFC 1350, opzioni in RFC da 2347 a 2349	Nessuna: nessuna autenticazione, nessuna crittografia
Raccogliere i log dei dispositivi	Syslog	UDP 514, o TLS su TCP 6514	RFC 5424, RFC 5426, RFC 5425	UDP: nessuna. TLS: crittografia e autenticazione del server

Di cosa hai bisogno prima di iniziare?

La configurazione è leggera, ma cinque elementi determinano il suo funzionamento fin dal primo giorno.

• Una rete di gestione. Posiziona le interfacce di gestione dei dispositivi su una VLAN di gestione. Una VLAN è una rete logica separata che esegue sugli stessi switch fisici. Questo mantiene il traffico SNMP, TFTP e syslog isolato dal traffico degli ospiti e del personale.
• Un host di gestione fisso. Utilizza un laptop o un jump host su quella VLAN con un indirizzo statico. I dispositivi inviano log e trap a un indirizzo fisso, quindi un indirizzo variabile interrompe la raccolta in modo silenzioso.
• Credenziali. Crea un utente SNMPv3 con autenticazione e privacy dove il firmware lo supporta. Se devi utilizzare v2c, modifica la stringa di community predefinita e limitala all'accesso in sola lettura dal tuo host di gestione.
• Sincronizzazione dell'ora. Indirizza ogni dispositivo alla stessa sorgente NTP. Senza di essa, i timestamp del syslog di dispositivi diversi non possono essere allineati durante un guasto.
• Regole del firewall. Consenti UDP 161 dal tuo host verso i dispositivi. Consenti UDP 162 e UDP 514 dai dispositivi al tuo host. TFTP richiede UDP 69 più le porte successive descritte di seguito.

Come il modello di gestione del tuo fornitore modifica il piano

Le piattaforme gestite in cloud mantengono la configurazione nel loro cloud, quindi il backup TFTP è meno importante in quel contesto. SNMP e syslog offrono comunque una vista locale del comportamento dei dispositivi.

Vendor	Modello di gestione	Dove risiede la configurazione	Cosa fa ancora uno strumento locale
Cisco Meraki	Dashboard cloud Meraki	Dashboard Meraki	Riceve syslog, interroga SNMP dove abilitato nella dashboard
HPE Aruba	CLI su switch AOS-S e AOS-CX, o Aruba Central	Sullo switch, specchiata in Central se utilizzato	Interrogazione SNMP, syslog, copia della configurazione TFTP
Ruckus	CLI su switch ICX, o controller Ruckus e gestione cloud	Sullo switch	Interrogazione SNMP, syslog, copia della configurazione TFTP
Juniper Mist	Cloud Mist che gestisce switch Junos EX	Cloud Mist	Interrogazione SNMP e syslog da Junos
Ubiquiti UniFi	Applicazione UniFi Network	Backup dell'applicazione UniFi Network	Syslog remoto, SNMP dove abilitato
Cambium	cnMaestro, o gestione locale su switch cnMatrix	cnMaestro o lo switch	Interrogazione SNMP e syslog
Extreme	CLI su Switch Engine (EXOS), o ExtremeCloud IQ	Sullo switch	Interrogazione SNMP, syslog, copia della configurazione TFTP
Fortinet	GUI o CLI di FortiGate e FortiSwitch, o FortiManager	Sul dispositivo	Interrogazione SNMP, syslog, backup della configurazione TFTP da CLI

Gli switch Cisco Catalyst che eseguono IOS o IOS XE non rientrano nel modello Meraki. La loro configurazione risiede sullo switch e si copia su un server TFTP da CLI.

Come si configurano l'interrogazione SNMP, i backup TFTP e un ricevitore syslog?

Netforge Network Multi-Tool integra un client SNMP, un server TFTP e un ricevitore syslog. Una singola installazione sul tuo host di gestione copre tutti e tre i passaggi seguenti. Gli stessi passaggi funzionano con strumenti standalone se li stai già eseguendo.

Passaggio 1: eseguire un SNMP walk senza un MIB browser

Non è necessario un MIB browser per ottenere risposte utili. Un MIB traduce solo i numeri in nomi. Esegui il walk sul ramo numerico corretto e i valori parleranno da soli. Inizia con questi quattro rami standard:

• 1.3.6.1.2.1.1 (gruppo di sistema). Restituisce sysDescr (stringa del modello e del firmware), sysUpTime, sysName e sysLocation. Definito nella norma RFC 3418.
• 1.3.6.1.2.1.2.2 (ifTable). Restituisce le descrizioni delle interfacce, lo stato operativo, gli errori e i contatori di traffico a 32 bit. Definito in RFC 2863.
• 1.3.6.1.2.1.31.1.1 (ifXTable). Restituisce contatori ad alta capacità a 64 bit e gli alias delle interfacce inseriti come descrizioni delle porte.
• 1.3.6.1.4.1 (private enterprise branch). Restituisce valori specifici del fornitore sotto i numeri d'impresa assegnati da IANA. Il numero di Cisco, ad esempio, è 9.

In Netforge, inserisci l'indirizzo del dispositivo, le tue credenziali SNMP e un OID iniziale, quindi avvia un walk. Ciascun risultato viene letto come un OID, un tipo e un valore. Una STRING sotto sysDescr viene letta come testo semplice. Un valore Timeticks sotto sysUpTime conta i centesimi di secondo dall'avvio dell'agente.

Se preferisci la riga di comando, lo snmpwalk di Net-SNMP esegue lo stesso compito:

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth-passphrase> -x AES -X <priv-passphrase> <switch-address> 1.3.6.1.2.1.1

Inizia in modo mirato. Un walk dalla root su un grande switch di core può restituire decine di migliaia di righe e andare in time out. Esegui il walk su un singolo ramo, trova ciò di cui hai bisogno, quindi usa un get per quel singolo OID la volta successiva.

Leggi il traffico dai contatori a 64 bit. Un contatore di ottetti a 32 bit si azzera a circa 4,29 miliardi di byte. Su un collegamento a 1 Gbps alla velocità di linea, questo azzeramento avviene all'incirca ogni 34 secondi. RFC 2863 richiede contatori di ottetti a 64 bit su interfacce più veloci di 20 Mbps esattamente per questo motivo.

Passaggio 2: esegui un server TFTP per i backup della configurazione dello switch

Avvia il server TFTP in Netforge, scegli una cartella root e consenti la scrittura dei file. Quindi invia la configurazione dal dispositivo al tuo host. Il comando varia a seconda del fornitore:

• Cisco IOS e IOS XE: copy running-config tftp: richiede l'indirizzo del server e un nome file.
• HPE Aruba AOS-S: copy running-config tftp seguito dall'indirizzo del server e dal nome del file.
• Extreme Switch Engine (EXOS): tftp put con l'indirizzo del server e i dettagli del file.
• Fortinet FortiGate: execute backup config tftp seguito da un nome file e dall'indirizzo del server.

Verifica la guida ai comandi del tuo fornitore per la sintassi esatta sulla tua versione del firmware. Assegna a ciascun file il nome host e la data, in modo che un ripristino non recuperi mai la configurazione dello switch errato. Sposta i backup completati dall'host TFTP a uno spazio di archiviazione protetto.

I caricamenti del firmware funzionano allo stesso modo ma al contrario. Le immagini di dimensioni superiori a circa 32 MB possono fallire su server limitati a blocchi di 512 byte. Il contatore dei blocchi a 16 bit si esaurisce a quella dimensione. L'opzione blocksize in RFC 2348 elimina il limite laddove entrambe le estremità lo supportino.

Spegni il server TFTP al termine. TFTP non prevede autenticazione, quindi un server sempre attivo rappresenta un punto di deposito file aperto sulla tua rete di gestione.

Passaggio 3: esegui un ricevitore di syslog e SNMP trap

Indirizza l'host di logging di ciascun dispositivo verso l'indirizzo del tuo host di gestione. Quindi imposta una soglia di gravità. Le gravità del syslog vanno da 0 (Emergency) a 7 (Debug). L'invio da 0 a 5 (Notice) acquisisce guasti e modifiche di stato senza sovraccaricare il ricevitore. Imposta un dispositivo su Debug solo durante la ricerca di un guasto specifico.

Aggiungi il tuo host come destinazione trap SNMP con le stesse credenziali utilizzate per il polling. Abilita le notifiche standard da SNMPv2-MIB e IF-MIB: coldStart, linkDown, linkUp e authenticationFailure. Utilizza gli inform al posto dei trap dove il dispositivo li supporta. Un inform attende una conferma, quindi un avviso perso viene reinviato.

Il ricevitore syslog Netforge mostra i log e i trap nello stesso strumento utilizzato per il polling e il trasferimento dei file. Ciò elimina la necessità di eseguire Kiwi Syslog Server insieme a Tftpd64 e a un MIB browser separato.

Scenario reale: un hotel da 200 camere ripristina uno switch guasto

Situazione. Un hotel di 200 camere gestiva 14 switch: due core e 12 di accesso. Un problema di alimentazione ha bloccato uno switch di accesso che serviva due piani per gli ospiti. Non esisteva alcun backup della configurazione. L'ingegnere ha ricostruito le VLAN e le impostazioni delle porte basandosi su foto e memoria, richiedendo un'intera giornata di lavoro.

Cosa è stato fatto. L'IT manager ha configurato un host di gestione con TFTP, SNMP e syslog in un unico strumento. La configurazione di ogni switch veniva scaricata sul server TFTP settimanalmente e prima di ogni modifica. Un SNMP walk mensile del gruppo di sistema registrava ogni modello e versione del firmware. Tutti i 14 switch inviavano syslog e trap allo stesso ricevitore.

Risultato. Quando un secondo switch di accesso si è guastato, il ricambio arrivato era dello stesso modello. L'ingegnere ha caricato la configurazione della settimana precedente dal server TFTP. Gli ospiti di quei piani sono tornati online in meno di un'ora, rispetto a un'intera giornata la prima volta. I team degli hotel che gestiscono reti WiFi per gli ospiti su larga scala affrontano lo stesso scenario in ogni struttura: vedi Hotel.

Come verificare che funzioni?

Testa ogni protocollo rispetto a un risultato noto prima di fare affidamento su di esso.

• SNMP. Ottieni sysUpTime due volte a distanza di un minuto. Il valore dovrebbe aumentare di circa 6.000 centesimi di secondo. Conferma che sysName corrisponda al nome host previsto.
• Backup TFTP. Apri il file salvato e leggilo. Una configurazione Cisco IOS termina con la riga end, quindi un file tronco si nota subito. Confronta le dimensioni del file con il backup precedente.
• Ripristino TFTP. Ripristina un backup su uno switch di riserva o di laboratorio. Un backup che non è mai stato ripristinato è solo una speranza, non un piano di disaster recovery.
• Syslog e trap. Chiudi e riabilita una porta inutilizzata. Dovresti vedere un trap linkDown e uno linkUp, oltre alle relative righe di syslog. I loro timestamp dovrebbero coincidere al secondo se il protocollo NTP funziona correttamente.
• Copertura. Conferma che ogni dispositivo nel tuo inventario abbia inviato almeno una riga di log nelle ultime 24 ore. Un dispositivo silenzioso è solitamente un dispositivo configurato in modo errato.

Cosa può andare storto e come rimediare?

La maggior parte dei problemi è riconducibile a firewall, credenziali o interfacce di origine. Questa tabella associa i sintomi comuni alle relative soluzioni.

Sintomo	Causa probabile	Soluzione
La richiesta SNMP va in timeout	L'access list del dispositivo blocca il tuo host, o la porta UDP 161 è filtrata	Aggiungi il tuo host alla access list SNMP e apri la porta UDP 161
SNMPv3 non riesce con un errore di autenticazione	Mancata corrispondenza dell'algoritmo di autenticazione o di crittografia	Allinea le impostazioni SHA e AES su entrambi i lati, quindi reinserisci le password
Walk restituisce i dati di sistema ma nulla nel ramo enterprise	Il controllo degli accessi basato sulle visualizzazioni (RFC 3415) limita ciò che l'utente può vedere	Ampliare la visualizzazione SNMP per l'utente in sola lettura
Il trasferimento TFTP si avvia, poi si blocca	Il firewall o il NAT bloccano la porta successiva da cui risponde il server	Consentire l'intervallo di porte di trasferimento del server o mantenere il TFTP all'interno di una sola VLAN
Scrittura TFTP rifiutata	Il server non crea nuovi file o i permessi delle cartelle bloccano la scrittura	Consentire la creazione di file nel server e verificare i permessi delle cartelle
Il firmware di grandi dimensioni non riesce a metà percorso	Limite di blocchi da 512 byte raggiunto a circa 32 MB	Abilitare l'opzione blocksize o utilizzare l'upload SCP o HTTP del fornitore
Nessun syslog arriva	Il dispositivo invia da un'interfaccia diversa o il firewall dell'host blocca la porta UDP 514	Configurare l'interfaccia di origine del logging e consentire la porta UDP 514 in ingresso
I log appaiono fuori ordine	I dispositivi non sono sincronizzati con NTP	Configurare la stessa sorgente NTP su ogni dispositivo
I grafici delle interfacce si appiattiscono o saltano	Wrap del contatore a 32 bit	Interrogare ifHCInOctets e ifHCOutOctets da ifXTable

Quanto costa e cosa si ottiene in cambio?

Il costo reale della gestione dei dispositivi è rappresentato dal tempo dei tecnici e dai tempi di inattività, non dal software. Confrontate i tre approcci più comuni sulle variabili che li guidano entrambi.

Approccio	Strumenti da installare	Protocolli coperti	Progettato per	Ideale per
Freeware monouso	Tre: Tftpd64, Kiwi Syslog Server, un browser MIB	TFTP e syslog, trap SNMP tramite Kiwi, polling SNMP tramite browser	Attività ad hoc, uno strumento per ogni lavoro	Un tecnico che ha già familiarità con tutti e tre
Multi-tool leggero (Netforge Network Multi-Tool)	Uno	SNMP get e walk, server TFTP, ricevitore syslog e trap	Polling su richiesta, trasferimenti e log in tempo reale	Piccole proprietà, lavoro sul campo degli MSP, singoli siti
NMS completo	Una piattaforma più un database e un server	SNMP, syslog, trap, oltre a discovery, grafici e instradamento degli avvisi	Monitoraggio continuo e cronologia delle tendenze a lungo termine	Proprietà grandi o multi-sito con team reperibili

Quando è necessario un NMS completo

Uno strumento leggero legge lo stato quando richiesto. Un NMS completo controlla continuamente e memorizza. Passate a un NMS completo quando si verifica una di queste condizioni:

• Avete bisogno di settimane di cronologia delle interfacce per la pianificazione della capacità.
• Gli avvisi devono contattare un tecnico reperibile alle 3 del mattino senza che nessuno debba guardare uno schermo.
• La vostra proprietà si estende su decine di siti, come le stazioni di una rete ferroviaria. Vedere Treni.
• I revisori si aspettano report automatici anziché file esportati manualmente.

Al di sotto di questa soglia, un NMS completo aggiunge un server, un database e manutenzione per funzioni che non utilizzerete.

Scenario pratico: una catena retail di 40 negozi individua guasti di collegamento nascosti

Situazione. Un MSP supportava una catena di 40 negozi. Ogni negozio utilizzava un firewall Fortinet FortiGate e due switch. I team dei negozi segnalavano che i terminali delle carte andavano offline diverse volte alla settimana. Le visite dei tecnici non rilevavano nulla, poiché il guasto era già stato risolto prima del loro arrivo. Cosa è stato fatto. L'MSP ha indirizzato i syslog e le trap SNMP di tutti i 120 dispositivi verso un unico ricevitore tramite la VPN site-to-site esistente. Ogni switch ha inviato trap di linkDown e linkUp. Il team ha monitorato quotidianamente il ricevitore per due settimane.

Risultato. I log hanno evidenziato ripetuti fenomeni di link flap sulle porte di uplink in tre punti vendita, in perfetta corrispondenza con gli orari delle disconnessioni segnalate. Sotto la guida remota del team, il personale del negozio ha sostituito tre cavi patch difettosi. L'MSP ha così azzerato le uscite reattive per quel guasto e i tre punti vendita non hanno più registrato disconnessioni dei terminali. Scopri di più su come le catene di vendita gestiscono le loro reti: Retail.

Conformità e gestione dei dati

I log dei dispositivi hanno un valore determinante per la conformità. Lo standard PCI-DSS richiede la modifica delle impostazioni predefinite dei fornitori e la versione 3.2.1 menziona esplicitamente le stringhe di community SNMP. Il requisito 10.5.1 della versione 4.0 di PCI-DSS impone di conservare i log di audit per almeno 12 mesi, di cui tre immediatamente disponibili. Il controllo 8.15 dell'Allegato A di ISO 27001 copre la registrazione degli eventi (logging).

Le righe di syslog possono contenere indirizzi IP e MAC, che possono essere considerati dati personali ai sensi del GDPR. Definisci un periodo di conservazione e limita l'accesso in lettura ai file del ricevitore. Questo aspetto è fondamentale nei settori regolamentati: vedi Healthcare.

Il ruolo di Purple

Purple è indipendente dall'hardware. Il nostro Guest WiFi funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, in oltre 80.000 sedi attive (dati Purple). Switch integri e ben documentati alla base rendono più semplice la gestione di qualsiasi servizio overlay. Lo strumento Netforge Network Multi-Tool offre ai tuoi tecnici la visibilità a livello di singolo dispositivo necessaria per mantenerli efficienti.

Domande frequenti

Ho bisogno di un NMS completo per gestire pochi switch?

No. Per un singolo sito o una rete di piccole dimensioni, il polling SNMP, i backup TFTP e un ricevitore syslog coprono la maggior parte delle attività di gestione quotidiane. Un NMS completo giustifica il suo costo quando si ha l'esigenza di un monitoraggio continuo, di settimane di storico dei trend, di sistemi di reperibilità automatizzati per i tecnici o di una gestione centralizzata su decine di sedi. Al di sotto di questa soglia, comporta solo un server, un database e costi di manutenzione aggiuntivi per funzionalità che non utilizzerai.

Posso eseguire un SNMP walk senza un MIB browser?

Sì. Un MIB si limita a tradurre gli OID numerici in nomi, quindi è possibile scorrere direttamente i rami numerici. Inizia con 1.3.6.1.2.1.1 per verificare modello, firmware e uptime, e con 1.3.6.1.2.1.31.1.1 per i nomi delle interfacce e i contatori di traffico a 64 bit. Lo strumento Netforge Network Multi-Tool esegue comandi get e walk partendo da un OID iniziale. Lo strumento snmpwalk di Net-SNMP esegue la stessa operazione da riga di comando.

Il protocollo TFTP è sicuro per il backup delle configurazioni degli switch?

Sì, a patto di limitarne l'ambito. Il protocollo TFTP non prevede autenticazione o crittografia secondo la specifica RFC 1350, quindi chiunque si trovi sul percorso di transito può leggere una configurazione. Attiva il server TFTP solo su una VLAN di gestione e solo durante le operazioni di backup o ripristino. Sposta i file finalizzati in uno spazio di archiviazione protetto. Laddove il tuo fornitore supporti SCP o SFTP, utilizza questi protocolli per i backup pianificati.

Funzionerà con il mio hardware esistente Cisco, Aruba o Fortinet?

Sì. SNMP, TFTP e syslog sono standard aperti supportati da Cisco IOS, HPE Aruba AOS-S e AOS-CX, Ruckus ICX, Extreme Switch Engine e Fortinet FortiGate. Le piattaforme gestite in cloud come Cisco Meraki, Juniper Mist e Ubiquiti UniFi conservano la configurazione nel proprio cloud. Su queste, è possibile utilizzare SNMP e syslog localmente ed effettuare il backup della configurazione tramite la piattaforma del vendor.

Uno strumento unico può sostituire Tftpd64 e Kiwi Syslog Server?

Sì. Netforge Network Multi-Tool include un server TFTP, un ricevitore syslog e SNMP trap, e funzionalità SNMP get e walk in un'unica applicazione. Questo sostituisce Tftpd64 per il trasferimento dei file e Kiwi Syslog Server per i log, eliminando la necessità di un MIB browser separato. Se si necessita di una conservazione dei log a lungo termine o del routing automatico degli avvisi, è possibile associarlo a una piattaforma di log o a un NMS completo.

I log dei dispositivi rientrano nell'ambito PCI-DSS e GDPR?

Sì, nella maggior parte dei casi. Il requisito 10.5.1 della versione 4.0 di PCI-DSS richiede che i log di controllo siano conservati per almeno 12 mesi, con tre mesi immediatamente disponibili, per i sistemi in ambito. Le righe di syslog possono includere indirizzi IP e MAC, che possono costituire dati personali ai sensi del GDPR. È necessario definire un periodo di conservazione, limitare l'accesso ai file di log e documentare entrambe le misure.

Quanto tempo richiede la configurazione per una piccola infrastruttura?

La maggior parte del lavoro riguarda la configurazione lato dispositivo piuttosto che lo strumento stesso. L'impostazione di un host di log, di una destinazione trap e di un utente SNMPv3 richiede pochi minuti per ogni switch da CLI. Per un sito con 14 switch, è da prevedere circa un pomeriggio di lavoro, inclusi i test e le regole del firewall. Le attività relative a NTP e VLAN di gestione, se non sono già presenti, richiedono solitamente più tempo rispetto alla configurazione dello strumento stesso.