13.3. Due parole su SNMP

Il troubleshooting è necessario per risolvere molti problemi che si possono verificare all'interno di una rete, una delle aspirazioni di un buon amministratore di rete è quella di non avere problemi. Il software che consente di effettuare il network management delle reti TCP/IP è principalmente basato sul protocollo Simple Network Management Protocol (SNMP). SNMP è un protocollo del tipo client/server che è descritto come protocollo di management e viene utilizzato per consentire la gestione di intere reti geografiche e di tenere sotto controllo qualsiasi tipo di apparato. Il Draft che descrive il protocollo SNMP è la RFC 1157 (http://www.ietf.org/rfc/rfc1157.txt).

Gli agent SNMP (un server, un apparato di rete, una risorsa in genere) si occupano di monitorare lo stato degli apparati di rete e trasmettono i dati o consentono l'analisi delle informazioni relative al loro stato di funzionamento. Il manager (il client SNMP) viene eseguito sulla Network Management Station (NMS), questa postazione è in effetti il collettore di tutte le informazioni provenienti dai vari apparati di rete, le informazioni vengono immagazzinate sulla base di dati che possono essere visualizzati in tempo reale. Esistono diversi applicativi che consentono di manipolare le informazioni fornite dalla stazione di NMS.

La maggioranza degli apparati TCP/IP vengono forniti con un agent SNMP, Squid è un software che, se opportunamente configurato, può tranquillamente funzionare come agent per fornire informazioni dettagliate sullo stato della webcache nonchè sul traffico che sta gestendo in un dato momento.

SNMP è un protocollo del tipo richiesta/risposta che utilizza lo User Datagram Protocol (UDP) per il trasporto dei pacchetti, l'agent rimane in ascolto sulla porta UDP 161 mentre la network managemente station (NMS) rimane in ascolto anche sulla porta UDP 162 per ricevere le trap che possono essere inviate dai vari agent. Secondo le specifiche di SNMPv1 e SNMPv2 il transito delle informazione utilizza un sistema di autenticazione che prende il nome di communities, le communities sono delle password in formato testo, ne consegue che il transito dai dati tra l'agent e l'nms è il punto debole del protocollo in quanto non viene utilizzato alcun sistema di crittografia. Le communities sono read-only, read-write e trap, ognuna di queste svolge un compito ben definito. La read-only consente di prelevare le informazioni dall'agent in sola lettura, la read-write è stata studiata per consentire agli utenti di eseguire la gestione remota dell'apparato (quindi consente di modificare le informazioni) e la trap invece autentica gli avvisi che vengono inviati dall'agent verso l'nms. Con il protocollo SNMPv3 è stato introdotto uno schema di autenticazione forte che consente di trasmettere le informazioni all'inteno di un canale sicuro (crittografato). Vista la debolezza del protocollo SNMPv1 ed SNMPv2 si consiglia sempre di utilizzare un firewall od un filtro IP che consenta la comunicazione tra i soli agent e la network management station (NMS) visto che il traffico potrebbe essere facilmente intercettato (sniffato). La richiesta e la risposta ai messaggi che SNMP invia nei datagrammi UDP viene chiamata Protocol Data Units (PDU).

13.3.1. Configurare l'agent SNMP di Squid

Abbiamo già detto che con la compilazione di Squid può essere incluso un agente Simple Network Managment Protocol (SNMP), unitamente all'agent Squid viene fornito anche di un MIB file che consentirà di gestire le variabili e gli oggetti più importanti. Per configurare il supporto SNMP è necessario compilare Squid con le seguenti opzioni di ./configure

% ./configure --enable-snmp
   

inoltre sarà necessario editare il file squid.conf per specificare una lista di communities, abbiamo visto in precedenza il significato di questo termine ed è possibile effettuare questa operazione utilizzando il TAG ACL riportato nell'esempio sottostante dove l'indirizzo IP 10.0.0.2 è quello della proxy appliance

acl locallan src 10.0.0.0/255.255.255.0 
acl localla1 src 10.0.1.0/255.255.255.0 
acl snmpManager src 10.0.0.2/255.255.255.255 
acl snmppublic snmp_community public 
acl snmpjoebloggs snmp_community joebloggs 
   

nel nostro caso, oltre alle access list che definiscono le subnet della rete locale verranno create ulteriori 3 nuove ACL

i nomi delle communities vengono determinati a piacere dall'amministratore del network. É necessario specificare una porta sulla quale deve rimanere in ascolto l'agente SNMP, per fare questo si utilizza il TAG snmp_port, la porta utilizzata come default da Squid è la 3401

snmp_port 3401 
   

è anche possibile effettuare il forward delle richieste SNMP su un'altro agent SNMP che in questo caso potrebbe già essere in ascolto sulla stessa macchina sulla quale è in funzione il nostro proxy, è possibile eseguire questa operazione utilizzando il seguente TAG

forward_snmp_port 
   

per autorizzare l'accesso all'agent SNMP di Squid devono essere definite le autorizzazioni per i TAG ACL che abbiamo creato in precedenza, ad esempio

snmp_access allow snmpManager 
snmp_access allow snmppublic localhost 
snmp_access allow snmppublic locallan 
snmp_access deny all 
   

nel nostro esempio l'agent SNMP potrà sempre essere avviato da snmpManager, ovvero la macchina che esegue il proxy potrà essere consultata da localhost (127.0.0.1) e la locallan (10.0.0.0/24), tutte le altre macchine della WAN non potranno accedere al servizio. Se non viene definita alcuna ACL, l'accesso SNMP è sempre vietato come standard predefinito. É anche possibile definire indirizzi IP determinati che legano l'agente SNMP di Squid per quello che concerne il traffico in entrata e quello in uscita, è possibile effettuare il bind facendo ricorso al seguente TAG

snmp_incoming_address 0.0.0.0 
snmp_outgoing_address 0.0.0.0 
   

dopo aver configurato correttamente l'agente SNMP è importante verificare che l'appliance Squid sia in ascolto sulla porta 3401 (predefinita), per effettuare questa verifica è necessario utilizzare il comando netstat(8) (sistemi Linux e FreeBSD)

% netstat -na |grep udp|grep 3401 
udp        0      0 0.0.0.0:3401            0.0.0.0:* 
   

verificato il funzionamento dell'agente SNMP possiamo finalmente testare il funzionamento del proxy server Squid.

13.3.2. Net-snmp

Possiamo finalmente provare le funzionalità dell'agent SNMP di Squid utilizzando i tools che vengono inclusi nel pacchetto net-snmp (http://net-snmp.sourceforge.net/). Installiamo net-snmp su un sistema FreeBSD

% cd /usr/ports/net-mgmt/net-snmp
% make install clean
   

se utilizziamo una qualsiasi distribuzione Linux o un'altro sistema UNIX® potremmo anche procedere con la compilazione e l'installazione manuale di net-snmp, come potete vedere il processo è molto semplice

% tar zxvf net-snmp-5.1.2.tar.gz
% cd net-snmp-5.1.2
% ./configure
% make
% su
% make install
   

copiamo il MIB file di Squid nella directory che contiene tutti i MIB files utilizzati da net-snmp, il percorso di destinazione del MIB file può variare e questo fatto può dipendere dal sistema operativo utilizzato

% cp /usr/local/etc/squid/mib.txt /usr/local/share/snmp/mibs/SQUID-MIB.txt
% chmod 444 /usr/local/share/snmp/mibs/SQUID-MIB.txt
   

su una macchina Red Hat Linux 7.3 che utilizza ucd-snmp ovvero la versione precedente di net-snmp i file MIB sono ubicati in una directory diversa

% cp /usr/local/squid/share/mib.txt /usr/share/snmp/mibs/SQUID-MIB.txt
% chmod 444 /usr/share/snmp/mibs/SQUID-MIB.txt
   

il MIB file è stato copiato nella directory come file di sola lettura, a questo punto utilizziamo l'utility snmpget(8) che consente di comunicare con una entità di rete utilizzando una richiesta SNMP di tipo GET

% snmpget -m SQUID-MIB -c public klingon.merlinobbs.net:3401 \
squid.cacheConfig.cacheAdmin
enterprises.nlanr.squid.cacheConfig.cacheAdmin = squid@merlinobbs.net
   

se dovessimo ottenere una risposta contenente un errore, questo significa che snmpget(8) non riesce a trovare il MIB file di Squid, se invece non dovessimo ottenere risposta, oppure ottenessimo un errore di timeout potemmo anche supporre che Squid non sia stato configurato per utilizzare SNMP oppure le ACL impostate sono troppo restrittive e non consentono di interrogare l'agent.

% snmpget -m SQUID-MIB -c public klingon.merlinobbs.net:3401 \
squid.cacheConfig.cacheAdmin
snmpget: Timeout
   

l'opzione -m indica all'utility snmpget(8) di utilizzare il MIB file SQUID-MIB, l'opzione -c indica il nome della community, per finire klingon.merlinobbs.net:3401 è il nome dell'host e la porta dove l'agent SNMP è in ascolto. Potremmo utilizzare anche l'utility snmpwalk(8) che comunica con una entità di rete utilizzando una richiesta SNMP del tio GETNEXT.

% snmpwalk localhost:3401 public .1.3.6.1.4.1.3495.1.1 
enterprises.3495.1.1.1.0 = 84 
enterprises.3495.1.1.2.0 = 12916 
enterprises.3495.1.1.3.0 = Timeticks: (1326) 0:00:13.26
% snmpwalk localhost:3401 public .1.3.6.1.4.1.3495.1.1 
enterprises.3495.1.1.1.0 = 84 
enterprises.3495.1.1.2.0 = 171000 
enterprises.3495.1.1.3.0 = Timeticks: (8406) 0:01:24.06
   

in questo esempio non vengono utilizzate opzioni, localhost:3401 è il nome della macchina locale (127.0.0.1) e la porta dove rimane in ascolto l'agent SNMP, public è il nome della community SNMP. Gli esempi mostrano chiaramente come interagiscono gli oggetti di una Network Management Station (NMS) con gli agent SNMP.

13.3.3. Controllare i processi utilizzando Net-snmp

In precedenza abbiamo citato il tipo di processi che dovremmo sempre tenere sotto controllo per verificare costantemente il nostro sistema di webcache, ora analizziamo nel dettaglio i processi e come utilizzare il Simple Network Management Protocol (SNMP) per ottenere questo tipo di informazioni

13.3.3.1. process size

la grandezza dei processi può avere un grande impatto sulle prestazioni di Squid, se il processo diviene troppo grande il sistema operativo utilizzerà una parte del disco per salvare le operazioni nella partizione di swap, lo OID[1] incluso nel MIB[2] file di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize = 0
    

13.3.3.2. page fault rate

le prestazioni di Squid possono soffrire quando la grandezza del processo supera la memoria fisica del sistema, analizzare il processo page fault rate è un ottimo sistema per tenere sotto controllo questo tipo di problema. Un page fault si verifica quando un programma richiede di accedere in un area di memoria che è stata swappata sul disco, lo OID incluso nel MIB file di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults = Counter32: 768
    

13.3.3.3. HTTP request rate

l'HTTP request rate è l'insieme delle richieste che vengono effettuare dai client verso Squid, se abbiamo avuto notizia che Squid sia divenuto lento alle richieste degli utenti possiamo determinare l'effettivo aumento delle HTTP request rate, lo OID incluso nel MIB file di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheProtoClientHttpRequests

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheProtoClientHttpRequests
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheProtoClientHttpRequests = Counter32: 399
    

13.3.3.4. ICP request rate

Se utilizziamo dei proxy server in relazione tra loro (parent o sibling) dovremmo controllare le richieste ICP in quanto vi sono dei problemi piuttosto importanti che possono essere relazionati con le query ICP. lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheIcpPktsRecv

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheIcpPktsRecv
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheIcpPktsRecv = Counter32: 0
    

13.3.3.5. Denied requests

Abbiamo detto in precedenza che dovremmo sempre ricevere un numero molto limitato di messaggi di errore (deny access, miss etc.), un'alta percentuale di errori può indicare un problema che è occorso nella realizzazione delle ACL o una cattiva configurazione dei client, oppure che qualcuno sta cercando di attaccare in nostro server. Questo tipo di errori possono essere analizzati direttamente dal file di log access.log

13.3.3.6. HTTP service time

Con il termine HTTP service time si identifica la lunghezza di una transazione HTTP competa, ovvero il tempo che intercorre tra la richiesta effettuata dal client e la risposta trasmessa al client. HTTP median service time è il tempo medio di risposta, questo tipo di misurazione può andare da un minimo di 100 ms ad un massimo di 500 ms, questa informazione può variare sulla base di alcuni fattori come il tipo di connettività internet. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheHttpAllSvcTime.5

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheHttpAllSvcTime.5
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheHttpAllSvcTime.5 = 0
    

13.3.3.7. DNS service time

Con il termine DNS service time viene indicato il tempo necessario a risolvere un nome internet da parte di un sistema Domain Name System (DNS), abbiamo detto in precedenza che un tempo di risposta molto elevato nella risoluzione di un nome può indicare un problema con il nostro DNS primario. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheDnsSvcTime.5

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheDnsSvcTime.5
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheDnsSvcTime.5 = 0
    

13.3.3.8. File descriptor aperti

Come abbiamo già spiegato dettagliatamente, i descrittori di file rappresentano il totale dei file e dei socket di rete aperti in un dato momento. Questo tipo di controllo può essere effettuato unitamente agli HTTP connection rate e gli HTTP service time. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt = Gauge32: 1011
    

13.3.3.9. Utilizzo della CPU

Abbiamo già detto che l'utilizzo della CPU dipende da vari fattori, tra questi possiamo elencare le opzioni di configurazione che abbiamo abilitato durante la compilazione di Squid e la grandezza della cache. Una unità a disco particolarmente lenta può divenire un collo di bottiglia che può far crescere esponenzialmente il tempo di utilizzo della CPU. Altre opzioni che utilizzano pesantemente la CPU sono il cache-digest, il CARP e le liste di URLs basate sulle regular expression. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage = 0
    

13.3.3.10. Spazio su disco

Lo spazio su disco è una delle risorse che viene maggiormente utilizzata da Squid, il messaggio di errore notificato agli utenti quando si verifica una condizione di spazio esaurito è "no space left on device". Quando si riceve questo tipo di messaggio, il processo (PID) Squid va in errore e l'applicazione va in crash, questo tipo di informazione è disponibile unicamente utilizzando l'interfaccia del cache manager di Squid di cui parleremo in seguito

13.3.3.11. Hit ratio

Cache Hit ratio è un'altro tipo di misurazione che può variare molto frequentemente nell'arco temporale, queste continue variazioni non sono un buon indicatore per la rilevazione di un problema. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheRequestHitRatio.5

% snmpget -m SQUID-MIB -c public localhost:3401 \
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheRequestHitRatio.5
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheRequestHitRatio.5 = 0
    

Note

[1]

OID - Object ID o identificativo dell'oggetto

[2]

MIB - SNMP Management Information Base