Monitorare le performance di un Pix

Quando il network è lento, il firewall ha funzionamenti  erranti e tutto sembra complicarsi è utile avere gli strumenti di base per diagnosticare eventuali problemi o condizioni di stress di un Pix.
Oltre ad accorgimenti minimi, in fase di configurazione, sono disponibili alcuni comandi validi per capire cosa succede al proprio Pix.
Le informazioni qui riassunte derivano da un interessante nota tecnica presa dal sito Cisco e linkata come fonte, in questo caso sostanzialmente unica, di questo testo.

Interfacce di rete
Per un Pix è fondamentale avere interfacce di rete che non perdono pacchetti per problemi fisici o di configurazione a livello di data link.
Come per ogni server o dispositivo di rete, destinato ad essere collegato stabilmente ad una porta di uno switch, è opportuno settare manualmente velocità e duplex del link, sia sull'interfaccia del Pix, che sulla relativa porta dello switch. Il settaggio automatico di default, può ritardare la negoziazione del link (problema solo iniziale) e, se è unilaterale, può dare problemi di duplex mismatch. Nel dubbio impostare un full duplex a 10 o 100, verificando la bontà dei cavi utilizzati e la mancanza di interferenze.
A livello della porta dello switch, inoltre, è opportuno rimuovere la negoziazione automatica di  etherchannel e trunking (su un Pix, di solito, non si usano: l'etherchanneling non è supportato, mentre il trunking VLAN lo è solo dalla release 6.x).
Può essere inoltre utile attivare il PortFast (o Fast Start) Forwarding a livello della porta di uno switch (Cisco) a cui è collegato il Pix.
In genere problemi fisici di rete si rivelano con percentuali relativamente alte nei counter dei runts, input errors, CRC, frame sulle interfacce di rete.

Logging e troubleshooting
Il Pix supporta il logging su un syslog server remoto, che può essere molto comodo per tenere sotto controllo messaggi di errore e attività di debugging. Le attività di logging possono essere piuttosto pesanti e degradare le prestazioni del sistema. In genere vale la pena impostare il livello di log a debugging solo in caso di attività di troubleshooting diretto, altrimenti attivare il logging su un syslog server remoto (qui 10.0.2.150) con minore verbosità:
logging on
logging host 10.0.2.150
logging trap warning

Rallentamenti per timeout di identd e reverse DNS lookup
Spesso delle prestazioni di rete deludenti dipendono dalla implementazione di determinati protocolli più che da veri problemi di networking. In particolare accade che alcuni server (ftp, telnet, smtp...) a seconda di come sono implementati e configurati eseguano delle query identd (un protocollo di identificazione dell'utente che si collega al servizio, di fatto totalmente inutile) o DNS (reverse lookup per ottenere il nome di un host di cui si sa l'indirizzo IP) relative ai client che si collegano. Se a queste query non vengono fornite risposte rapide (perchè sul client gira un server identd, o è stato configurato il reverse del suo IP sul server DNS utilizzato), l'utente deve attendere che le stesse vadano in timeout prima di accedere al servizio remoto.
Per risolvere questo tipo di problemi (si manifestano tipicamente in alti tempi di attesa al momento di un collegamento ad un server e poi a successive normali velocità di interazione) si può intervenire in vari modi:
- Disattivare a livello del server in questione l'uso di query identd o reverse DNS.
- Configurare sui propri server DNS (quelli che vengono usati dalle macchine su cui girano i servizi interessati) le zone di reverse (in-addr.arpa) per tutti gli IP dei client che si collegano (se possibile).
- Mettere a mano negli /etc/hosts dei server il mapping IP del client remoto e relativo nome (soluzione sporca ma rapida).
- Configurare il Pix per rispondere con un esplicito e definitivo RST alle richieste Identd che gli arrivano sulle interfacce. Il comando da usare è: service reset inbound associato ad access-list che bloccano i pacchetti identd (tcp/113). In questo modo il Pix non droppa silenziosamente i pacchetti filtrati ma risponde con un RST al client. Notare che questo comando vale per ogni connessione e causa un maggiore carico dovuto ai pacchetti TCP RST di risposta.

Comandi Utili per valutare l'utilizzo delle risorse
La command line del PIX presenta vari comandi utili per valutare lo stato delle risorse disponibili. Quelle più importanti sono la memoria, la CPU time, la disponibilità di buffer per i pacchetti in coda, il numero di translazioni e connessioni gestite.

show cpu usage - Visualizza l'utilizzo di CPU negli ultimi 5 secondi, 1 minuto, 5 minuti.
Le attività che consumano più CPU sono la criptazione di dati per le VPN e in parte il logging in locale (meglio loggare su remoto, senza esagera in verbosità).
Per vedere il dettaglio della CPU utilizzata dai singoli processi utilizzare show processes e tenere d'occhio in particolare la colonna runtime, e come questa varia dopo alcuni minuti. Di fatto indica quanto CPU time in millisecondi è stata utilizzata da un processo dall'avvio. Il processo 557poll dovrebbe essere quello più oneroso, in quando controlla il traffico sulle interfacce fastethernet.  Se il processo Logger occupa troppe risorse su un sistema sotto stress vale la pena disattivare o ridurre ogni forma di logging.

show memory - Visualizza la memoria RAM totale e quella disponibile.
Il Pix carica in RAM rispettivamente l'immagine del sistema operativo, la configurazione, alloca spazio per i buffer (blocks) e tiene in memoria le tabelle di natting (xlate) e le connessioni che sta gestendo. Generalmente una volta terminato il boot, la RAM occupata reta stabile, e tende ad aumentare solo sotto grossi carichi di traffico. Se la RAM finisce il Pix, probabilmente, si inchioda.

show blocks - Visualizza i blocchi di buffer liberi per i pacchetti che il Pix sta gestendo. L'output si divide secondo le dimensioni dei pacchetti (in genere il normale traffico è messo in blocchi da 1550 byte, mentre i pacchetti per il logging remoto o la sincronizzazione delle informazioni di failover stateful sono in blocchi da 256 byte) e alcuni counter che rappresentano rispettivamente il Massimo numero di blocchi disponibili (MAX), il numero minimo di blocchi liberi raggiunti (LOW) e il numero corrente di blocchi disponibili (CNT). Quando il CNT arriva a zero, il Pix alloca menoria per ulteriori blocchi (fino ad un massimo di 8192), se questo non basta, inizia a droppare pacchetti. E' normale aver il LOW a 0 per blocchi da 256 e 1550, ma se il CNT è costantemente a 0 il Pix potrebbe non bastare a gestire adeguatamente il traffico che gli viene sottoposto.

show traffic - Visualizza informazioni sul traffico passato per interfaccia. Utilizzare clear traffic per azzerare i relativi contatori.
show interface - Visualizza altri dati sulle interfacce, gli errori e i pacchetti trasferiti. Il contatore no buffers indica quanti pacchetti sono stati droppati per esaurimento dei blocks, le collisions non dovrebbero esistere su interfacce in full duplex e su quelle in half duplex non dovrebbero superare il 10% di tutti i pacchetti in entrata e in uscita. Se uno dei counter degli errori aumenta costantemente esiste un problema che va risolto in quanto intacca sicuramente le performance.

show perfmon - Comodo per vedere il numero di connessioni, xlates e altri operazioni che il router sta gestendo. Da valori in numero al secondo correnti e medi.

show xlate - Visualizza le traslazioni che il Pix sta gestendo (NAT, PAT). Se si vogliono visualizzare soltanto i totali, senza il dettaglio delle singole xlate, digitare show xlate count
Analogamente show conn mostra le connessioni TCP e UDP correnti e show conn count dei valori riassuntivi. Sempre in termini di traffico gestito, show local-host fornire ulteriori informazioni interessanti.
Un numero esagerato di connections può essere sintomo di un DOS attack, un numero esagerato di xlate può indicare attività di spoofing da parte di un host interno (sintomo di una potenziale violazione dello stesso).
E' possibile, in configurazione, definire i tempi di timeout per connessioni e translazioni, vanno generalmente abbassati, rispetto ai valori di default, se si è sotto attacco DOS.

Pix Device Manager (PDM)
Il PDM è stato introdotto dalla release 6.0 del Pix Operative System. Permette la configurazione e il monitoring di un Pix via browser, fra le sue caratteristiche permette di visualizzare dati storici su vari parametri. Questi dati possono essere visualizzati anche via command line con comandi tipo show pdm history 10m snapshot. Per attivare questo meccanismo di raccolta informazioni si deve interventire in conf mode con pdm history enable.

Privacy Policy