Informazioni sui comandi Ping e Traceroute
Sommario
Introduzione
In questo documento viene descritto l'uso dei comandi ping e traceroute sui router Cisco.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Premesse
Nel presente documento, questa configurazione di base viene utilizzata per gli esempi riportati in questo articolo:
Configurazione di base di IP e router
Il comando ping
Il comando ping è un metodo molto comune utilizzato per risolvere i problemi di accessibilità dei dispositivi. Utilizza una serie di messaggi echo ICMP (Internet Control Message Protocol) per determinare:
-
Indica se un host remoto è attivo o inattivo.
-
Ritardo di andata e ritorno utilizzato per comunicare con l'host.
-
Perdita di pacchetti.
Il comando ping invia un pacchetto di richiesta echo a un indirizzo, quindi attende una risposta. Il ping ha esito positivo solo se:
-
la richiesta echo raggiunge la destinazione e
-
la destinazione è in grado di ottenere una risposta echo per l'origine entro un tempo predeterminato denominato timeout. Il valore predefinito di questo timeout è due secondi sui router Cisco.
Impossibile modificare il valore TTL di un pacchetto ping.
Nell'esempio di codice successivo viene mostrato il comando ping dopo l'attivazione del comando debug ip packet detail.
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms Router1# Jan 20 15:54:47.487: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 15:54:47.491: ICMP type=8, code=0 !--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12.
!--- ICMP type=8 corresponds to the echo message. Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3 Jan 20 15:54:47.527: ICMP type=0, code=0 !--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message.
!--- By default, the repeat count is five times, so there will be five
!--- echo requests, and five echo replies.
Valori possibili di tipo ICMP
| Tipo ICMP | Valore letterale |
|---|---|
| 0 | eco-risposta |
| 3 | codice destinazione non raggiungibile 0 = rete non raggiungibile 1 = host non raggiungibile 2 = protocollo non raggiungibile 3 = porta non raggiungibile 4 = frammentazione richiesta e DF impostato 5 = route origine non riuscita |
| 4 | attenuazione dell'origine |
| 5 | codice di reindirizzamento 0 = datagrammi di reindirizzamento per la rete 1 = datagrammi di reindirizzamento per l'host 2 = datagrammi di reindirizzamento per il tipo di servizio e rete 3 = datagrammi di reindirizzamento per il tipo di servizio e host |
| 6 | indirizzo-alternativo |
| 8 | eco |
| 9 | annuncio router |
| 10 | richiesta router |
| 11 | tempo scaduto codice 0 = tempo di produzione scaduto in transito 1 = tempo di riassemblaggio del frammento scaduto |
| 12 | problema di parametro |
| 13 | timestamp-request |
| 14 | timestamp-reply |
| 15 | richiesta di informazioni |
| 16 | risposta informativa |
| 17 | maschera-richiesta |
| 18 | maschera-risposta |
| 31 | errore-conversione |
| 32 | mobile-redirect |
Possibili caratteri di output dalla funzione Ping
| Carattere | Descrizione |
|---|---|
| ! | Ogni punto esclamativo indica la ricezione di una risposta. |
| . | Ogni punto indica che il server di rete è scaduto in attesa di una risposta. |
| U | È stata ricevuta una PDU di destinazione non raggiungibile. |
| D | Arresto dell'origine (destinazione troppo occupata). |
| M | Impossibile frammentare. |
| ? | Tipo di pacchetto sconosciuto. |
| e | Durata pacchetto superata. |
Impossibile eseguire il ping
Se non è possibile eseguire il ping su un indirizzo IP, tenere presente le cause elencate in questa sezione.
Problema del router
Di seguito sono riportati alcuni esempi di tentativi di ping non riusciti, che possono determinare il problema e cosa fare per risolverlo. L'esempio è mostrato con il seguente diagramma della topologia di rete:
Problemi del router
Router1# ! interface Serial0 ip address 172.16.12.1 255.255.255.0 no fair-queue clockrate 64000 ! Router2# ! interface Serial0 ip address 10.0.2.23 255.255.255.0 no fair-queue clockrate 64000 ! interface Serial1 ip address 172.16.0.12 255.255.255.0 ! Router3# ! interface Serial0 ip address 172.16.3.34 255.255.255.0 no fair-queue ! interface Serial1 ip address 10.0.3.23 255.255.255.0 ! Router4# ! interface Serial0 ip address 172.16.4.34 255.255.255.0 no fair-queue clockrate 64000 !
Provare a eseguire il ping tra il router4 e il router1:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Risultati:
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:00:25.603: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:27.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:29.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:31.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:33.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Success rate is 0 percent (0/5)
Poiché nessun protocollo di routing viene eseguito sul router1, il router non sa a chi inviare il pacchetto e genera un messaggio "unrouteable" (instradabile).
Aggiungere una route statica al router1:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Risultati:
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.663: ICMP type=8, code=0 Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:30.695: ICMP type=3, code=1 Jan 20 16:05:30.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.703: ICMP type=8, code=0 Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.703: ICMP type=8, code=0 Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:32.735: ICMP type=3, code=1 Jan 20 16:05:32.739: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.743: ICMP type=8, code=0
Esaminare gli errori sul router2:
Router2#debug ip packet detail IP packet debugging is on (detailed) Router2# Jan 20 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.911: ICMP type=8, code=0 Jan 20 16:10:41.915: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:41.919: ICMP type=3, code=1 Jan 20 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.951: ICMP type=8, code=0 Jan 20 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.947: ICMP type=8, code=0 Jan 20 16:10:43.951: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:43.955: ICMP type=3, code=1 Jan 20 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.987: ICMP type=8, code=0 Jan 20 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:45.983: ICMP type=8, code=0 Jan 20 16:10:45.987: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:45.991: ICMP type=3, code=1
Il router1 ha inviato correttamente i pacchetti al router2, ma il router2 non sa come accedere all'indirizzo 172.16.4.34. Il router2 invia al router1 un messaggio "ICMP non raggiungibile".
Abilitare il protocollo RIP (Routing Information Protocol) sul router2 e sul router3:
Router2# router rip network 172.16.0.7 network 10.0.7.23 Router3# router rip network 10.0.7.23 network 172.16.0.34
Risultati:
Router1#debug ip packet IP packet debugging is on Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:16:13.367: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:15.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:17.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:19.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:21.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Il router1 invia i pacchetti al router4, ma quest'ultimo non restituisce una risposta.
Possibile problema sul router 4:
Router4#debug ip packet IP packet debugging is on Router4# Jan 20 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:45.911: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:47.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:49.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:51.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:53.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Il router 4 riceve i pacchetti ICMP e cerca di rispondere alla richiesta 172.16.12.1, ma non avendo un percorso verso questa rete, ha esito negativo.
Aggiungere una route statica al router4:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Ora entrambi i lati possono accedere l'uno all'altro:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Interfaccia giù
In questo caso, l'interfaccia non funziona più. Nell'esempio successivo viene mostrato un tentativo di eseguire il ping tra il router4 e il router1:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
Poiché il routing è corretto, eseguire una procedura dettagliata per risolvere il problema. Provare a eseguire il ping sul router2:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Nell'esempio precedente, il problema è tra il router2 e il router3. È possibile che l'interfaccia seriale sul router3 sia stata chiusa:
Router3#show ip interface brief Serial0 172.16.3.34 YES manual up up Serial1 10.0.3.23 YES manual administratively down down
Questo è semplice da correggere:
Router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router3(config)#interface serial1 Router3(config-if)#no shutdown Router3(config-if)# Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Comando Access-list
In questo scenario, solo il traffico telnet può accedere al router4 tramite l'interfaccia Serial0.
Router4(config)# access-list 100 permit tcp any any eq telnet Router4(config)#interface serial0 Router4(config-if)#ip access-group 100 in Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#access-list 100 permit ip host 172.16.12.1 host 172.16.4.34 Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1 Router1(config)#end Router1#debug ip packet 100 IP packet debugging is on Router1#debug ip icmp ICMP packet debugging is on
Provare a eseguire il ping del router4:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending
Alla fine di un comando access-list viene sempre visualizzato un messaggio di rifiuto implicito per tutti. Ciò significa che i pacchetti ICMP che entrano nell'interfaccia 0 seriale sul router 4 vengono rifiutati e il router 4 invia un messaggio ICMP "indirizzi irraggiungibili per l'amministrazione" all'origine del pacchetto originale, come mostrato nel messaggio di debug. Per risolvere il problema, aggiungere questa riga nel comando access-list:
Router4(config)#access-list 100 permit icmp any any
Problema Address Resolution Protocol (ARP)
Questo scenario prevede la connessione Ethernet:
Problema Address Resolution Protocol
Router4#ping 172.16.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: Jan 20 17:04:05.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:05.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:07.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:07.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:09.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:09.183: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:11.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:11.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:13.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:13.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Success rate is 0 percent (0/5) Router4#
Nell'esempio, il ping non funziona a causa del messaggio "incapsulamento non riuscito". Ciò significa che il router sa su quale interfaccia deve inviare il pacchetto, ma non sa come farlo. In questo caso, è necessario comprendere il funzionamento del protocollo ARP (Address Resolution Protocol).
ARP è un protocollo utilizzato per mappare l'indirizzo MAC (Layer 2 address) a un indirizzo IP (Layer 3 address). Per verificare questa condizione, usare il comando show arp:
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.7 10 0060.5cf4.a955 ARPA Ethernet0
Tornare al problema "incapsulamento non riuscito", ma questa volta abilitare il comando debug arp:
Router4#debug arp
ARP packet debugging is on
Router4#ping 172.16.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 172.16.100.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
L'output precedente mostra che il router4 invia i pacchetti all'indirizzo di broadcast Ethernet FFFF.FFFF.FFFF. In questo caso, il valore 0000.0000.0000 indica che il router4 cerca l'indirizzo MAC della destinazione 172.16.100.5. Poiché non conosce l'indirizzo MAC mentre l'ARP è richiesto in questo esempio, utilizza 0000.000.000 come segnaposto nei frame di broadcast inviati dall'interfaccia Ethernet 0 e chiede quale indirizzo MAC corrisponde a 172.16.100.5. Se non è disponibile una risposta, l'indirizzo MAC corrisponde all'indirizzo IP nell'output del comando show arp ed è contrassegnato come incompleto:
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.5 0 Incomplete ARPA Internet 172.16.100.7 2 0060.5cf4.a955 ARPA Ethernet0
Dopo un periodo predeterminato, questa voce incompleta viene eliminata dalla tabella ARP. Se l'indirizzo MAC non è presente nella tabella ARP, il ping ha esito negativo a causa di un "errore di incapsulamento".
Ritardo
Per impostazione predefinita, se non si riceve una risposta dal terminale remoto entro due secondi, il ping ha esito negativo:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Nelle reti con un collegamento lento o un ritardo prolungato, due secondi non sono sufficienti. È possibile modificare questa impostazione predefinita con un ping esteso:
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: 30 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 30 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
Per ulteriori informazioni sul comando ping esteso, vedere Informazioni sui comandi ping esteso e traceroute esteso.
Nell'esempio precedente, quando il timeout è stato aumentato, il ping è riuscito.
Indirizzo origine corretto
Questo esempio è uno scenario comune:
Indirizzo origine corretto
Aggiungere un'interfaccia LAN sul router1:
Router1(config)#interface ethernet0 Router1(config-if)#ip address 10.0.0.1 255.255.255.0
Da una stazione sulla LAN, è possibile eseguire il ping tra il router1 e il router2, ma non tra il router2 e una stazione sulla LAN.
Dal router1, è possibile eseguire il ping sul router2 perché, per impostazione predefinita, l'indirizzo IP dell'interfaccia in uscita viene utilizzato come indirizzo di origine nel pacchetto ICMP. Il router2 non dispone di informazioni su questa nuova LAN. Se deve rispondere a un pacchetto proveniente da questa rete, non sa come gestirlo.
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms Router1# Jan 20 16:35:54.227: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3
L'esempio di output precedente funziona perché l'indirizzo di origine del pacchetto inviato è 172.16.12.1. Per simulare un pacchetto proveniente dalla LAN, è necessario usare un ping esteso:
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: Jan 20 16:40:18.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:20.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:22.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:24.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:40:26.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Questa volta, l'indirizzo di origine è 10.0.0.1 e non funziona. I pacchetti vengono inviati ma non viene ricevuta alcuna risposta. Per risolvere il problema, aggiungere una route alla versione 10.0.0.0 nel router2. La regola base è che il dispositivo con ping deve essere in grado di inviare la risposta all'origine del ping.
Numero elevato di errori nella coda di input
Quando un pacchetto entra nel router, il router tenta di inoltrarlo a livello di interrupt. Se non è possibile trovare una corrispondenza in una tabella cache appropriata, il pacchetto viene inserito nella coda di input dell'interfaccia in ingresso da elaborare. Alcuni pacchetti vengono sempre elaborati, ma con la configurazione appropriata e in reti stabili, la velocità dei pacchetti elaborati non deve mai congestionare la coda di input. Se la coda di input è piena, il pacchetto viene scartato.
Anche se l'interfaccia è attiva, non è possibile eseguire il ping sul dispositivo a causa di cadute elevate della coda di input. È possibile controllare le perdite di input con il comando show interface.
Router1#show interface Serial0/0/0
Serial0/0/0 is up, line protocol is up
MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec,
reliability 255/255, txload 69/255, rxload 43/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 01:28:49
Input queue: 76/75/5553/0 (size/max/drops/flushes);
Total output drops: 1760
Queueing strategy: Class-based queueing
Output queue: 29/1000/64/1760 (size/max total/threshold/drops)
Conversations 7/129/256 (active/max active/max total)
Reserved Conversations 4/4 (allocated/max allocated)
Available Bandwidth 1289 kilobits/sec
!--- Output supressed
Come si evince dall'output, la perdita della coda di input è elevata. Per risolvere i problemi relativi alle perdite nella coda di input/output, consultare il documento sulla risoluzione dei problemi relativi alle perdite nelle code di input e di output.
Il comando traceroute
Il comando traceroute viene usato per trovare i percorsi usati dai pacchetti per raggiungere la destinazione. Il dispositivo (ad esempio, un router o un PC) invia una sequenza di datagrammi UDP (User Datagram Protocol) a un indirizzo di porta non valido sull'host remoto.
Vengono inviati tre datagrammi, il cui valore TTL (Time-To-Live) è uno. Quando il valore TTL è 1, il datagramma "scade" non appena incontra il primo router del percorso; questo router risponde quindi con un messaggio ICMP "Tempo scaduto" (TEM) per segnalare che il datagramma è scaduto.
Vengono ora inviati altri tre messaggi UDP, il cui valore TTL è 2, in modo che il secondo router restituisca gli ICMP. Questo processo continua finché i pacchetti non raggiungono effettivamente l'altra destinazione. Poiché questi datagrammi provano ad accedere a una porta non valida sull'host di destinazione, vengono restituiti messaggi ICMP Port Unreachable (Porta non raggiungibile) e questo indica che non è possibile accedere alla porta. questo evento determina la fine del programma Traceroute.
Lo scopo di questo messaggio è registrare l'origine dei messaggi ICMP "Time Exceeded" (Tempo scaduto) per fornire una traccia del percorso del pacchetto verso l'indirizzo di destinazione.
Router1#traceroute 172.16.4.34 Type escape sequence to abort. Tracing the route to 172.16.4.34 1 172.16.0.12 4 msec 4 msec 4 msec 2 10.0.3.23 20 msec 16 msec 16 msec 3 172.16.4.34 16 msec * 16 msec Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.615: UDP src=39911, dst=33434 Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.639: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router2. Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.647: UDP src=34237, dst=33435 Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.671: ICMP type=11, code=0 Jan 20 16:42:48.675: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.679: UDP src=33420, dst=33436 Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.703: ICMP type=11, code=0
Questa è la prima sequenza di pacchetti inviata con un valore TTL=1. Il primo router, in questo caso Router2 (172.16.0.12), scarta il pacchetto e lo invia all'origine (172.16.12.1) un messaggio ICMP tipo=11. Corrisponde al messaggio Tempo scaduto.
Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.711: UDP src=35734, dst=33437 Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.747: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router3. Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.755: UDP src=36753, dst=33438 Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.791: ICMP type=11, code=0 Jan 20 16:42:48.795: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.799: UDP src=36561, dst=33439 Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.831: ICMP type=11, code=0
Lo stesso processo si verifica per il router3 (10.0.3.23) con un valore TTL=2:
Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!--- Port Unreachable message from Router4.
Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Con un TTL=3, il router4 è finalmente raggiunto. Questa volta, poiché la porta non è valida, il router4 restituisce al router1 un messaggio ICMP con tipo=3, un messaggio destinazione irraggiungibile e codice=3 che indica la porta non raggiungibile.
Nella tabella seguente vengono elencati i caratteri che possono essere visualizzati nell'output del comando traceroute.
Caratteri di testo tracciamento routing IP
| Carattere | Descrizione |
|---|---|
| nn msec | Per ogni nodo, il tempo di andata e ritorno in millisecondi per il numero di richieste specificato |
| * | Timeout della sonda |
| A | Divieto amministrativo (ad esempio, elenco degli accessi) |
| D | Rallentamento origine (destinazione troppo occupata) |
| I | Test interrotto dall'utente |
| U | Porta non raggiungibile |
| H | Host non raggiungibile |
| N | Rete non raggiungibile |
| P | Protocollo non raggiungibile |
| T | Timeout |
| ? | Tipo di pacchetto sconosciuto |
Prestazioni
Il tempo di andata e ritorno (RTT) può essere ottenuto con i comandi ping e traceroute. Questo è il tempo necessario per inviare un pacchetto echo e ricevere una risposta. Questo può fornire un'idea approssimativa del ritardo sul collegamento. Tuttavia, tali cifre non sono abbastanza precise da poter essere utilizzate per la valutazione delle prestazioni.
Quando una destinazione è il router stesso, il pacchetto deve essere commutato in base al processo. Il processore deve gestire le informazioni di questo pacchetto e inviare una risposta. Questo non è l'obiettivo principale di un router. Per definizione, un router è progettato per instradare i pacchetti. Il ping con risposta viene offerto come servizio il più possibile efficiente.
Per illustrare questa condizione, questo è un esempio di ping tra il router1 e il router2:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Il formato RTT è di circa quattro millisecondi. Dopo aver abilitato alcune funzionalità che richiedono molte operazioni sul router2, provare a eseguire il ping tra il router2 e il router1.
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Qui l'RTT è aumentato notevolmente. Il router2 è piuttosto occupato e la priorità non è rispondere al ping. Un modo migliore per verificare le prestazioni del router è tramite il traffico che attraversa il router.
Traffico attraverso il router
Il traffico viene quindi commutato rapidamente e gestito dal router con la priorità più alta. La rete di base illustra quanto segue:
Router Basic Network 3
Eseguire il ping tra router3 e router1:
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Il traffico passa attraverso il router2 e ora è a commutazione rapida. Abilitare la funzionalità di elaborazione intensiva sul router2:
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Non c'è quasi nessuna differenza. Infatti, sul router2, i pacchetti vengono ora gestiti a livello di interrupt.
Uso del comando debug
Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.
I diversi comandi debug usati in questo articolo mostrano cosa succede quando si usa un comando ping o traceroute. Questi comandi consentono di risolvere i problemi. Tuttavia, in un ambiente di produzione, i debug devono essere utilizzati con cautela. Se la CPU non è potente o se si dispone di molti pacchetti a commutazione di contesto, è possibile che il dispositivo venga bloccato con facilità. Per ridurre al minimo l'impatto del comando debug sul router, è possibile procedere in due modi. Un modo consiste nell'utilizzare gli elenchi degli accessi per limitare il traffico specifico che si desidera monitorare.
Di seguito è riportato un esempio:
Router4#debug ip packet ?
<1-199> Access list
<1300-2699> Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 172.16.12.1 host 172.16.4.34 (5 matches)
Con questa configurazione, il router4 stampa solo il messaggio di debug che corrisponde all'elenco degli accessi 150. Un ping dal router1 determina la visualizzazione del messaggio:
Router4# Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3
La risposta al problema non viene dal router4 perché questi pacchetti non corrispondono all'elenco degli accessi. Per visualizzarli, aggiungere:
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1
Risultati:
Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending
Per ridurre l'impatto del comando debug è anche possibile inserire i messaggi di debug nel buffer e visualizzarli con il comando show log dopo aver disattivato il debug:
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 172.16.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
I comandi ping e traceroute sono utilità utili per risolvere i problemi di accesso alla rete. Sono anche molto facili da usare. Questi due comandi sono ampiamente utilizzati dai tecnici di rete.
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
04-Oct-2022 |
Certificazione |
1.0 |
10-Dec-2001 |
Versione iniziale |
Feedback