Per ottenere i migliori risultati in fase di debugging, ci sono alcune tecniche che e’ bene usare e fare in modo che diventino una abitudine.

Con i miei consigli si evita la perdita di informazioni importanti, e’ piu semplice per altri analizzare e capire le informazioni che tu hai catturato e ti danno la possibilita’ di essere piu’ accurato nel riportare quello che hai visto.

Un problema di rete tipicamente puo’ essere:

• un cavo collegato alla porta sbagliata
• un apparato configurato male
• un problema di interoperabilita’ fra apparati
• un guasto hardware di una parte o di tutto un apparato
• un bug del software in un apparato

La sessione di debugging ti deve aiutare nel troubleshooting del problema e quindi nel trovare la causa del problema.
Oppure i tuoi test o il materiale che raccogli puo’ essere uno strumento utilissimo ad altre persone per capire la natura del problema, come in caso di apparati o software di terzi di cui tu pero’ hai in gestione il monitoraggio.
Per questo il materiale che raccogli deve essere

• in quantita’ sufficiente
• contenere le giuste informazioni

Consiglio n. 1

Cattura tutto.

Da quando colleghi il tuo emulatore di terminale o sessione telnet/ssh all’ apparato, inizia a catturare.
Registrerai un sacco di materiale apparentemente inutile, ma sicuramente non perderai nessuna informazione importante.

Consiglio n. 2

Cattura lo stato iniziale.

Appena arrivi cerca di catturare piu’ informazioni possibili sullo stato attuale, POI inizia a fare i test di troubleshooting.
Quindi cattura lo stato delle interfacce, le informazioni sul routing, lo stato dei protocolli, i counter, e tutto quello che puo’ essere pertinente.

per apparati Cisco:

show running-config
show interface
show ip route
show ip ospf
show ip bgp summary

Consiglio n. 3

Scrivi i tuoi pensieri e azioni.

E’ molto probabile che qualcun altro analizzera’ il tuo debug in un secondo tempo oppure avrai bisogno di riguardarlo tu stesso.
Quindi sara’ utilissimo avere delle spiegazioni sul

• perche’ hai guardato uno specifico counter o richiesto uno specifico status all’ apparato.

• la relazione del capture rispetto ad un evento (p.es. dopo che la eth va giu’ questo e’ l’ output dello show interface)

Quindi puoi inserire commenti cosi’ come ti viene naturale per commentare quello che stai osservando, quello che stai facendo o la “pista” che stai seguendo per scoprire il malfunzionamento.
Vanno benissimo commenti come:

“ho tolto la scheda 3 e ora vediamo come si comporta …”
“questo contatore cresce troppo in fretta, vediamo se disabilitando l’ OSPF cambia qualcosa..”
” il ping sul 2.2.2.2 continua a fallire…”

E inoltre quando incontri qualcosa di veramente interessante o importante evidenzialo con caratteri come !!!!!!!!!!! o ########### in modo che saltino all’ occhio di una persona che sta scorrendo velocemente il file.

Consiglio n.4

Dai un particolare comando “show” un po di volte in successione.

Spesso l’ investigazione e la conferma di una teoria richiede che controlli cosa sta cambiando, per esempio il contatore degli errori su una specifica porta.

Consiglio n. 5

Se stai investigando problemi in cui il tempo e’ significativo, dai uno “show clock” prima di ogni comando.

In questo modo, se puo’ essere significativo la velocita’ a cui cambiano le cose, fissa tu il “timestamp” ad ogni comando di show che dai all’ apparato.

Consiglio n.6

Se trovi una sequenza di azioni che fa scattare il problema, cattura la sequenza (e la prova che il problema si e’ verificato) interamente e piu’ di 2 volte, se ti e’ possibile.

Se sei arrivato ad una teoria sul vero motivo del malfunzionamento, produci una prova a supporto da passare alle altre persone. E che sia convincente.

Consiglio n. 7

Un po di rimaneggiamento e di editing del file di debug puo’ far guadagnare un sacco di tempo a chi lo analizzera’ dopo di te.

Quando mandi il tuo file di debug allo strato di supporto superiore o a chiunque altro, vorrai guidarli al meglio su come estrarre le parti importanti di informazione dal tuo capture.
Puoi aggiungere ulteriori commenti per spiegare meglio cosa sta succcedendo, oppure puoi copiare le parti importanti in un file separato, per illustrare succintamente il problema.

Consiglio n.8
Se possibile, manda sempre TUTTO quello che hai catturato. Troppa informazione e’ sempre meglio che troppo poca.

Manda il file grezzo insieme a quello “riordinato”, potrebbero esserci informazioni preziose che ti sono sfuggite.

Spero che tutto questo ti sia utile. I suggerimenti sono benvenuti, commenta pure sotto