CCNA02 Ch09

Cisco CCNA - Modulo 2 - Capitolo 9
Troubleshooting di base
sul router
Di
Francesco Immè
Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Esaminando la routing table
La prima funzione di un router è determinare il best path per una

destinazione.
Il comando show ip route visualizza il contenuto della routing table IP,
che contiene entries per tutte le reti e sottoreti conosciute, nonché un
codice che indica come le info relative sono state acquisite.
• show ip route connected
• show ip route network
• show ip route rip
• show ip route igrp
• show ip route static
Una routing table mappa i “prefissi” ad una interfaccia verso l’esterno.
Quando un router riceve un pacchetto destinato a 192.168.4.46 cerca
per il prefisso 192.168.4.0/24 nella sua tavola.

Esaminando la routing table (2)
A seconda di quanto scritto nella tavola lui gira il pacchetto ad una determinata
interfaccia.
Altre route si possono aggiungere in due modi:
• Un amministratore definisce le route per la rete di destinazione (static routing)
• I router seguono le regole del routing protocol per avere informazioni (dynamic
routing)
Ambedue i metodi hanno vantaggi e svantaggi.

Esaminando la routing table (3)

Determinare il gateway di last
resort
I router mantengono una default route o gateway of last resort. Una
caratteristica chiave delle default route è che mantengono la routing
table molto scarna.
Un amministratore per settare una default route può usare i comandi:
ip default-network
ip route 0.0.0.0 0.0.0.0
Il primo comando serve a far stabilire la default route nelle reti che usano i
protocolli di routing dinamici.
Il comando ip default-network 192.168.17.0 deinisce una rete di classe C
come destination path per pacchetti che non hanno entries nella routing
table. Per ogni rete configurata con ip default-network se un router ha
una route verso la rete, quella route è segnata come candidata a
default route.

Determinare il gateway di last
resort (2)
Creare una ip route verso
0.0.0.0/0 è un altro modo
per configurare la route di
default.
Router(config)#ip route
0.0.0.0 0.0.0.0 [next-hop-
ip-address | exit-
interface]
Appena configurato una
default route o un default
network il comando show
ip route mostrerà
Gateway of last resort is
172.16.1.2 to network
0.0.0.0

Determinazione della sorgete e
destinazione di una route
Il path determination si ha al network layer quando il traffico va attraverso il
cloud della rete. La funzione path determination abilita un router a
valutare i path disponibili per una destinazione, al fine di stabilire un
trattamento dei pacchetto.
I servizi di routing usano informazioni topologiche (note tramite processi
dinamici o statici) quando vanno a valutare i path.
Il layer network fornisce una consegna best-effort ed end-to-end dei
pacchetti attraverso le reti interconnesse. Come è ovvio il network layer
usa una IP table routing per mandare i pacchetti da sorgente a
destinazione.
Appena il router stabilisce quale path usare prende il pacchetto e lo
forwarda sulla interfaccia adeguata.

Indirizzi di livello 2 e 3
Mentre gli indirizzi di layer network sono usati per portare i pacchetti dalla
sorgente alla destinazione è importante capire che un tipo diverso di indirizzi
viene usato per portare i pacchetti da un router al successivo.
Al fine di far giungere un pacchetto dalla sorgente alla destinazione sono usati
tanto gli indirizzi di layer 2 che di layer 3.
Nella figura della slide successiva ad ogni interfaccia, ogni volta che i pacchetti si
muovono lungo la rete, la routing table è esaminata ed il router determina il
next hop. Il pacchetto viene quindi forwardato usando l’indirizzo MAC del next
hop; l’indirizzo IP di sorgente e di destinazione non cambiano.
L’indirizzo di layer 3 è usato per instradare il pacchetto dalla rete di sorgente a
quella di destinazione; è per questo che gli indirizzi IP non cambiano, mentre i
MAC cambiano ad ogni hop. L’indirizzamento di data link layer è necessario
perché l’indirizzamento dentro una rete si compie mediante il frame header di
livello 2.

Indirizzi di livello 2 e 3 (2)

Determinare l’AD
Un router può scoprire le route
usando protocolli di routing
dinamici o anche mediante
route configurate
manualmente
dall’amministratore.
Non appena le route sono
scoperte o configurate il
router deve scegliere quali
sono le best route in una
data rete.
La distanza amministrativa (numero che misura l’affidabilità della sorgente che ha
suggerito la route) della route è l’informazione chiave che il router usa nel decidere
quale sia il best path verso una destinazione.
Più è basso l’AD più è affidabile la sorgente.
Protocolli di routing diversi hanno AD di default diverse. Se un path ha la AD più
bassa questo è quello installato nella routing table.
Determinare la metrica di routing
I routing protocol usano la metrica per determinare la miglior route per una
destinazione. La metrica è un valore che misura la desiderabilità di una route.
Alcuni protocolli di routing usano solo un fattore per calcolare la metrica. Ad
esempio RIP v1 usa solo l’hop count, altri un mix di vari fattori (hop count,
banda, delay, load, affidabilità, ticks delay, MTU e costo).
Ogni algoritmo di routing interpreta ciò che è meglio dal suo punto di vista.
L’algoritmo genera un numero, chiamato valore di metrica, per ogni path
attraverso la rete. Tipicamente tanto è minore il valore tanto migliore è il path.
Fattori come la banda ed il delay sono statici perché rimangono gli stessi per ogni
interfaccia sino a che il router non è riconfigurato o la rete non cambia.
Fattori come il carico e l’affidabilità sono dinamici perché sono calcolati per ogni
interfaccia in real-time.

Determinare la metrica di routing
(2)
Più sono i fattori che costituiscono una metrica, maggiore è la flessibilità di
confezionare operazioni di rete che incontrino i bisogni specifici.
Per default IGRP usa i fattori statici prima indicati. Banda e delay possono
essere configurati manualmente, permettendo un controllo preciso su
quale strada un router scelga.
IGRP può essere anche configurato per includere fattori dinamici (load ed
affidabilità). Così le decisioni possono essere prese basandosi su
situazioni attuali.
IGRP calcola la metrica addizionando valori pesati delle differenti
caratteristiche del link della rete in questione. Ad esempio banda,
banda divisa il carico ed il delay sono pesati con i fattori K1, K2 e K3:
Metrica = K1*banda + (K2*banda)/(256-load)+K3*delay
Le costanti di default sono K1=K3=1 e le altre a zero.

Determinare il next hop
Gli algoritmi di routing riempiono le tavole

di routing con molte informazioni. Le
associazioni destination/next hop
dicono ad un router che una
destinazione può essere raggiunta
mandando i pacchetti verso un router
in particolare. Questo rappresenta il
next hop.
Quando un router riceve un pacchetto
controlla l’indirizzo di destinazione e
cerca di associarlo ad un next hop.

Determinare il next hop (2)
I comandi qui di seguito possono essere

usati per sapere il last routing update:
•show ip route
•show ip route <network>
•show ip protocol
•show ip rip database

Determinare il next hop (3)

Multiple path
Alcuni protocolli di routing
supportano multiple path per la
stessa destinzaione. Questi
algoritmi permettono che il
traffico viaggi su più linee,
danno una portata migliore e più
affidabile. Rt1 ha 2 route verso
la rete 192.168.30.0. Il comando
variance deve essere settato
su Rt1 per usare i 2 path. La
figura mostra l’output del show
ip route prima che la variance
sia configurata. Serial 0/0 è
l’unica route verso
192.168.30.0.

Multiple path (2)
Dopo aver settato il comando variance
questo è l’output dello show ip
route.
La route preferita è l’interfaccia
FastEthernet 0/0, ma anche Serial
0/0 sarà usato.

Multiple path (3)
Per verificare il load balancing si
faccia un ping verso 192.168.30.1.
Appena il ping è eseguito la route
preferita usa l’interfaccia Serial 0/0;
questo perché IGRP usa il load
balancing tra i 2 link.

Introduzione al network testing
I test di base per la rete dovrebbero
essere tali da procedere da un
layer dell’OSI model al successivo.
Ovviamente è condigliabile partire
dal layer 1 per arrivare, se
necessario, fino al 7.
La maggior parte dei problemi che
capitano su reti IP sono errori nello
schema di indirizzamento. E’ bene
infatti fare un controllo a riguardo
prima di andare avanti nella
configurazione.

Troubleshooting
Il troubleshooting è un processo che permette all’utente di trovare il

problema che affligge la rete. Tale processo deve essere molto
ordinato e basato sugli standard di rete usati. La documentazione è
una parte molto importante del processo. Gli step solitamente sono:
1. Collect all available information and analyze the symptoms of failure
2. Localize the problem to within a single network segment, to a single
complete module or unit, or to a single user
3. Isolate the trouble to specific hardware or software within the unit,
module, or user’s network account.
4. Locate and correct the specific problem.
5. Verify that the problem has been solved.

Troubleshooting generico

Troubleshooting (2)
La figura nella slide successiva si ha un altro tipo di approccio al

troubleshooting (sono solo 2 dei possibili tipi).
Usare un approccio strutturato per il troubleshooting è importante perché
ogni membro del team di supporto sa quale step ogni membro del team
ha compiuto per risolvere il problema.
Se però il processo è lasciato un po’ al caso e senza documentazione né
organizzazione, il problem solving non è efficiente. Anche se il
problema viene superato in un ambiente non strutturato sarà
probabilmente impossibile duplicare la soluzione per problemi simile in
futuro.

Errori possibili al layer 1
Errori possibili a livello 1 sono:

• Broken cables
• Disconnected cables
• Cables connected to the wrong ports
• Intermittent cable connection
• Wrong cables used for the task at hand (must use rollovers, crossover
cables, and straight-through cables correctly)
• Transceiver problems
• DCE cable problems
• DTE cable problems
• Devices turned off

Errori possibili al layer 2 ed al 3
Al layer 2 invece si potrebbe avere:

• Improperly configured serial interfaces
• Improperly configured Ethernet interfaces
• Improper encapsulation set (HDLC is default for serial interfaces)
• Improper clockrate settings on serial interfaces
• Network interface card (NIC) problems
Per il layer 3:
• Routing protocol not enabled
• Wrong routing protocol enabled
• Incorrect IP addresses
• Incorrect subnet masks

Fare troubleshoot al layer 1
usando lo show interface
L’IOS Cisco è pieno di comandi utili per fare troubleshooting e tra i molti i più
ampiamente usati sono i comandi show, e questo perché tutti gli aspetti del
router possono essere visti con uno o più dei show command.
Il comando show interface (la cui sintassi si completa colla interfaccia interessate)
ci permette di verificare lo stato e le statistiche delle interfacce.
Lo stato di 2 porzioni importanti delle interfacce si può visionare con il comando
show interface: ci riferiamo alla porzione fisica (hardware) e logica (software),
che possono essere correlate alle funzioni di layer 1 e layer 2.
L’hardware include cavi, connettori ed interfacce che mostrano la condizione della
connessione fisica tra i device. Lo stato del software mostra l’indicazione dei
messaggi come i keepalive, i control information e le informazioni di utente che
sono passati tra device adiacenti.

usando lo show interface (2)
Se la linea è down il problema potrebbe essere nel cablaggio o
nell’equipment, se non addirittura nell’alimentazione o nell’aver settato
un capo del collegamento come amministrativamente down.
Il comando show interfaces serial permette di vedere altre info utili a
diagnosticare alrte cose relative al layer 1 non facili da diagnosticare.
Un numero alto di carrier transition counts su un link seriale può
indicare uno o più dei seguenti problemi:
• Interruzioni di linea dovute a problemi della rete del service provider
• hardware difettoso
Se il numero che aumenta è quello degli input error nell’output dello show
interfaces serial anche qui posso avere più problemi a livello 1:
• equipaggiamento della compagnia telefonica difettoso
• linea serial rumorosa
• Cavo non corretto o troppo lungo, danneggiato o connessione
danneggiata
• CSU o DCU difettoso
• Hardware del router difettoso
usando lo show interface (3)
Un’altra area da esaminare è il numero degli interface reset. Essi sono il risultato di
troppi keepalive mancati. Tale problema si può presentare per:
• Linea non buona che causa carrier transition
• Problemi coll’hardware
Se le transizioni di carrier ed i reset di interfaccia sono in crescita o se gli input error
sono tanti mentre i reset di interfacci stanno aumentando il problema è
probabilmente un bad link o un CSU/DSU difettoso.
Il numero di errore deve essere relazionato colla quantità di traffico che il router ha
processato e la quantità di tempo che è servita per prendere le statistiche usate.
Le statistiche riflettono le operazioni del router da quando è spartito o dall’ultimo
clear dei counter. Se con show interfaces ci dice quando è stato fatto l’ultimo
clear con show version sapremo da quanto il router è attivo.
Il comando clera counters resetta a zero i counter (cosa da fare ogni volta che si
incontrano problemi su una interfaccia).

.

usando lo show interface
Il comando show interface è forse il tool più importante per scoprire i
problemi del router ai livelli 1 e 2. Il primo parametro (line) si riferisce al
layer fisico, il secondo (protocol) indica se il processo dell’IOS che
controlla il line protocol considera l’interfaccia utilizzabile, cosa
determinabile dalla buona ricezione dei keepalives. I keepalive sono
messaggi mandati da un network device per informarne un altro che il
circuito virtuale tra loro è ancora attivo; se un’interfaccia manca 3
keepalive consecutivi allora il line protocol è marcato come down.
Se la line è down (non essendoci mezzo disponibile!!) anche il protocollo è
down. Se l’interfaccia è su ed il protocollo down esiste un problema di
livello 2, per problemi come:
• No keepalive
• No clock rate
• Tipo di incapsulazione non adatta

Troubleshooting usando show
cdp
CDP annuncia informazioni sui device ai suoi vicini, includendo indirizzi MAC ed IP
e interfacce di uscita. L’output del comando show cdp neighbors visualizza
informazioni sui “vicini” direttamente connessi.
Se si sospetta un problema di cablaggio si abilitino le interfacce con no shutdown

e fare quindi lo show cdp neighbors detail prima di qualsiasi configurazione. Il
comando farà vedere dettagli del device come le interfacce attive, i port ID ed il
device, nonché la versione di IOS che corre sui device remoti.
cdp (2)
Se il livello fisico funziona bene allora tutti i device Cisco direttamente
connessi dovrebbero essere visualizzati, se invece non compare
nessun device allora è probabile un problema di livello 1.
Una area che il CDP copre con attenzione è quella della sicurezza. La
quantità di informazione che il CDP offre è talmente elevata che
potrebbe essere un buco potenziale nella sicurezza.
Per questo CDP dovrebbe essere configurato solo su link tra device Cisco
e disabilitato su porte utente o link che non sono gestite localmente.

Troubleshooting usando
traceroute
Il comando traceroute è usato per scoprire le route che il pacchetto prende mentre
viaggia; può essere usato anche per fare un testing hop-by-hop a livello 3 e offre
performance benchmark.
Se il traceroute va buon fine, nel senso che il pacchetto arriva a destinazione,
l’output ci dirà la sequenza di hop passati per compiere il viaggio; se poi invece
c’è un problema ed un hop non è raggiungibile (presenza di asterischi)
comparando quanto accade colla situazione attuale potrei capire dove è la falla.
Il comando dà anche indicazioni sulle prestazione dei vari link; l’RTT è il tempo che
serve ad un pacchetto echo per essere spedito e per ricevere una risposta (utile
per stimare il delay di link). Queste sono valutazioni cmq non precise per una
performance evaluation. Il problema, come per il ping, è che chi subisce il
traceroute deve poter rispondere agli echo e quindi conoscere la via verso il
mittente, per cui una risposta fallita non è sempre indice di un problema (vero
soprattutto su Internet).

Troubleshooting usando
traceroute (2)
Traceroute manda una sequenza di datagrammi UDP dal router ad un
indirizzo di porta non valido di un host remoto. Per la sequenza dei
primi 3 datagrammi mandati un campo TTL ha valore messo ad 1. Il
TTL a tale valore causa lo scadere del datagramma al primo router del
path, il quale risponderà con un ICMP TEM che indica che il
datagramma è spirato.
Altri 3 messaggi UDP sono mandati con TTL 2 questa volta, cosa che
porta il secondo router a mandare degli ICMP TEM; il processo
prosegue sino a che i pacchetti non ricevono realmente la
destinazione.
Dato che i datagrammi stanno cercando di accedere ad una porta non
valida della destinazione ritornerà in ultima istanza non un ICMP TEM
ma un ICMP PUM.

Consigli per il routing
troubleshooting
I comandi show ip protocols e show ip route visualizzano info sui
protocolli di routing e le routing table, e tali output si possono usare per
verificare la configurazione del protocollo di routing.
Per fare troubleshooting sul routing il comando show ip route è forse il più
importante. Visualizza il contenuto della routing talbe, mostrando le
entries per tutte le reti e sottoreti conosciute, e come queste info sono
state imparate. Se c’è un problema nel raggiungere una rete in
particolare l’output del comando si deve usare per verificare che il
router ha una route verso quella rete. Se questo non è vero forse il
problema può essere nelle info di routing non scambiate, caso in cui è
utile usare il comando show ip protocols per vedere errori nella
configurazione del protocollo. Questo comando visualizza valori sul
protocollo di routing relative all’intero router e serve per vedere quali
protocolli sono configurati, quali reti sono avvisate, che interfacce
mandano gli update e le sorgenti degli update.

Consigli per il routing
troubleshooting (2)
L’output dello show ip protocols mostra anche i timer, i filtri, riassunto
delle route, ridistribuzione delle route ed altri parametri relativi ai vari
protocolli di routing abilitati. Se ve n’è più d’uno abilitato allora le info
retlative a ciascuno sono listate in una sezione separata.
L’output di tale comando può essere usato per diagnosticare moltissimi
problemi di routing. Può usarsi per confermare la presenza di protocolli
che si immaginavano implementati, verificare che delle reti sono
avvisate e che i vicini mandano notizie.
Come in ogni processo di troubleshoot se non c’è però una
documentazione adeguata non è possibile intervenire in maniera
oculata ed appropriata.

controllers serial
Spesso il troubleshooting sui router è fatto da remoto. Il comando show
controllers serial è decisamente utile per avere idea dei cavi connessi
senza poterli ispezionare visivamente.
Esaminando l’output del comando si può determinare il tipo di cavo che il
controller detetta. Ciò è utile pertrovare l’interfaccia seriale senza cavo,
con cavo di tipo errato o difettoso.
Il comando show controllers serial richiede un chip che controlli le
interfacce seriale e cisualizzi info sulle interfacce fisiche. L’output
varierà al variare del chip, può variare anche tra interfacce uguali dello
stesso router.
Altri dettagli che il comando ci dà col suo output sono dettagli tecnici
relativi lo stato del chip di controllo; tali info sono del tutto inutili senza
la conoscenza appropriata.

Il debug
Il comando debug assiste nell’isolare problemi di protocollo e di configurazione; è
usato per visualizzare dati ed eventi dinamici.
I comandi show fanno vedere informazioni statiche, danno una fotografia delle
operazioni del router. Col debug l’output da una visuale più approfondita della
situazione delle operazioni del router.
Gli eventi visualizzati possono essere traffico su interfacce, messaggi di errore
generati da nodi della rete, pacchetti di dignostica di protocolli ed altri dati utili
nel troubleshooting. L’output del debug viene fuori a un costo elevato a livello di
performance, producendo una lato overhead di processamento. Per questo il
debug non deve essere usato normalmente ma solo in caso di tentativi di
isolare i problemi.
Il comando debug all deve essere usato bene. Di default il router manda sulla
console ciò che viene dal debug; se si usa telnet evidentemente si deve avere
un redirect dei dati. Ciò viene fatto durante la sessione telnet tramite il comando
terminal monitor. L’uso del debug tramite telnet deve essere ancora più parco.
Una ottima regola è mai fare debug sulla porta su cui la sessione è stabilita.

Il debug (2)
Un servizio utile dell’IOS è porre un timestamp su ogni messaggio del

debug. Questa info fornisce il momento in cui si ha l’evento di debug e
la durata del tempo tra vari eventi. Il comando che vedremo a breve
permette di vedere l’ora:minuto:secondo dell’output, il tempo da cui il
router è stato acceso l’ultima volta e quando il reload è avvenuto
l’ultima volta:
GAD(config)#service timestamps debug uptime
Il comando no debug all o undebug all spegne tutte le diagnostiche.

CCNA02 Ch09

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CCNA02 Ch09

Caricato da

Copyright:

Formati disponibili

Cisco CCNA - Modulo 2 - Capitolo 9

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

La prima funzione di un router è determinare il best path per una

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Gli algoritmi di routing riempiono le tavole

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

I comandi qui di seguito possono essere

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Il troubleshooting è un processo che permette all’utente di trovare il

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

La figura nella slide successiva si ha un altro tipo di approccio al

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Errori possibili a livello 1 sono:

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Al layer 2 invece si potrebbe avere:

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Fare troubleshoot al layer 2

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Se si sospetta un problema di cablaggio si abilitino le interfacce con no shutdown

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Un servizio utile dell’IOS è porre un timestamp su ogni messaggio del

Copyright 2002 Cisco Press: CCNA Instructor’s Manual www.ciscopress.com

Potrebbero piacerti anche