Raccogliere informazioni ALCUNE DOMANDE FONDAMENTALI È stato modificato qualche componente HW o SW? Il sintomo si presenta regolarmente o ad intermittenza? Quando si è presentato per la prima volta il problema? Il sintomo è relativo a tutte le operazioni di rete o solo ad alcune applicazioni/connessioni? È stato collegato qualche nuovo dispositivo (Notebook, Stampante…) alla rete? È stato installato/aggiornato del software? Ci sono stati lavori di manutenzione? Sono stati fisicamente spostati degli apparati? …

Conservare informazioni Quando si verifica un errore, una prima indicazione sulla causa potrebbe essere fornita dal confronto tra le informazioni attuali e quelle raccolte precedentemente Informazioni raccolte durante l’insorgenza di altri errori Informazioni raccolte durante il normale funzionamento della rete (statistiche sull’uso della capacità, sul numero di timeout…) ANALIZZATORE DI PROTOCOLLO

Analizzatore di protocollo

Strumenti di diagnostica Molto utile è il protocollo ICMP (Internet Control Message Protocol) Ping Utilizzato per verificare la connettività a livello Rete tra due host, A e B –L’host A invia un pacchetto “echo request” –Alla ricezione di tale messaggio, l’host B risponde con un pacchetto “echo reply” Traceroute Utilizzato per scoprire il percorso seguito per raggiungere una destinazione –Viene inviata una serie di pacchetti “echo request” con TTL via via crescente, a partire da 1 –Il router che, decrementando il TTL, lo azzera, invierà a ritroso un messaggio “TTL exceeded” N.B.: Alcune politiche di Firewalling, impediscono il transito ai pacchetti ICMP Telnet È utile per stabilire connessioni TCP tra due host, indicando anche il numero di porto destinazione

Traceroute (1/9)

Traceroute (2/9)

Traceroute (3/9)

Traceroute (4/9)

Traceroute (5/9)

Traceroute (6/9)

Traceroute (7/9)

Traceroute (8/9)

Traceroute (9/9) c:\> tracert Rilevazione instradamento verso su un massimo di 30 punti di passaggio 154 ms 49 ms 49 ms ms 49 ms 49 ms ms 49 ms 49 ms ms 49 ms 69 ms Rilevazione completata. c:\>

Esempio Supponiamo di non riuscire a “navigare” sul sito web e vediamo come l’uso del comando ping può aiutare ad individuare la sorgente del problema.

Esempio ping _Impossibile trovare l’host Verificare che il nome sia corretto e riprovare. c:\> ping Esecuzione di Ping con 32 byte di dati: Risposta da : byte=32 durata=61ms TTL=117 Risposta da : byte=32 durata=60ms TTL=117 Risposta da : byte=32 durata=59ms TTL=117 Statistiche Ping per : Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi), Tempo approssimativo percorsi andata/ritorno in millisecondi: Minimo = 59ms, Massimo = 61ms, Medio = 59ms c:\>

Esempio Il ping all’indirizzo simbolico ha avuto esito negativo, mentre il ping all’indirizzo IP corrispondente ha avuto esito positivo. Questo è un chiaro segnale che il sintomo è in qualche modo correlato con il DNS

Scenario di rete A B L’host A non riesce a stabilire una connessione con l’host B

Localizzare il problema 1.Ping all’interfaccia di loopback ( ) dell’host B (problem host) 2.Ping all’host B da un altro host nella stessa sottorete 3.Ping dall’host B ad un altro host nella medesima sottorete 4.Ping dall’host B al router di default 5.Ping dall’host B ad altri host in diverse sottoreti 6.Ping all’host B attraverso il nome simbolico 7.Ping ad un altro host nella stessa sottorete dell’host B attraverso il nome simbolico 8.Ping ad un altro host in una differente sottorete attraverso il nome simbolico 9.Telnet all’host B, utilizzando il numero di porto specifico dell’applicazione che non risponde Livello IP Livello TCP

1) Loopback test Ping all’interfaccia di loopback del problem host Se ha esito negativo: L’interfaccia di rete non è operativa I driver TCP/IP non sono correttamente installati In alcuni Sistemi Operativi (es. Unix), l’interfaccia di loopback potrebbe funzionare anche se l’interfaccia di rete è “down”!!

2-3) Connettività intra-subnet Ping al problem host da una sorgente nella medesima sottorete Se ha esito negativo: Eseguire un test di loopback della sorgente Verificare che il problem host sia connesso alla rete Verificare l’indirizzo IP e la netmask del problem host Ping dal problem host ad una stazione nella medesima sottorete Se ha esito negativo: Verificare che il problem host sia connesso alla rete Verificare che il nodo di destinazione sia attivo Verificare l’indirizzo IP usato nel comando ping

4) Connettività col default router Ping dal problem host al router di default Se ha esito negativo: Verificare indirizzo IP e netmask del router Verificare la configurazione del router Verificare che l’interfaccia del router sia operativa Se ha esito positivo: Recuperare la tabella di instradamento del router e verificare che la rete di destinazione sia raggiungibile. Nel caso nessuna rotta specifica sia indicata per la rete di destinazione, almeno una rotta di default (default gateway) deve essere configurata

5) Connettività inter-subnet Ping dal problem host ad host in reti via via più lontane, connesse tramite router Si fa uso del traceroute per individuare il point of failure Il comando traceroute potrebbe mostrare solo parzialmente il path seguito dai pacchetti, in quanto i pacchetti potrebbero attraversare router che filtrano il traffico ICMP Non potendo determinare i cambiamenti nelle rotte seguite dai pacchetti, il comando traceroute andrebbe eseguito almeno tre volte di seguito per ottenere dei risultati affidabili

6-8) Connettività mediante nome simbolico Ping al problem host attraverso il suo nome simbolico piuttosto che l’indirizzo IP Se ha esito negativo: Verificare la connettività col server DNS (ping al DNS) Verificare che nelle tabelle di corrispondenza del DNS ci sia il corretto mapping alias name  IP address Ripetere i test intra-subnet e inter-subnet utilizzando i nomi simbolici

9) Connettività a livello TCP Nonostante ci sia perfetta connettività a livello Rete, alcune applicazioni potrebbero non essere in grado di comunicare in quanto L’applicazione dal lato ricevente non è attiva Uno dei router lungo il path potrebbe impedire il transito a pacchetti indirizzati a determinati numeri di porto Telnet al problem host sul porto specifico di una applicazione Anche messaggi di errore del tipo telnet: Unable to connect to remote host telnet: Connection refused costituiscono un’informazione sufficiente che lo stack TCP/IP è operativo e che il porto TCP destinazione è disponibile

Perdita intermittente della connettività Possibili cause: Rete sovraccarica Nodo destinazione sovraccarico Indirizzi IP duplicati Bridge/router malfunzionanti Cavi e connettori malfunzionanti In tutti questi casi, può essere d’aiuto un analizzatore di protocollo che: Fornisce informazioni e statistiche circa timeout, ritrasmissioni, etc. Può inviare richieste ARP

Local routing Questo fenomeno si presenta quando uno switch è direttamente connesso ad un router In tal caso, anche i pacchetti diretti a segmenti di rete attestati allo stesso switch saranno inoltrati al router che, a sua volta, li instraderà nuovamente allo switch… Duplicazione dei pacchetti Consumo delle risorse del router (buffer, CPU…) Questo problema può essere risolto collocando un analizzatore di protocollo tra lo switch ed il router Pacchetti con lo stesso numero di sequenza e TTL decrementato di 1, sono “prosciugati” Un altro scenario che può causare il fenomeno del local routing è quando due sottoreti diverse sono attive sul medesimo segmento

Frequenti cause di errore (1/3)

Frequenti cause di errore (2/3)

Frequenti cause di errore (3/3)