Soluzione dell'esame Demo TSHOOT

L'uscita del nuovo esame TSHOOT ha causato un po' di incertezza nelle persone che come me stanno percorrendo il percorso per ottenere la certificazione CCNP. Oggi ho trovato una demo ufficiale Cisco dell'esame TSHOOT e, piuttosto incuriosito da questa modalità, ho deciso di cimentarmici. Non nego che il primo tentativo è miseramente fallito, principalmente perché la fretta mi aveva fatto tralasciare le istruzioni. Vediamo quindi di analizzarlo con calma.

Il laboratorio di esempio prevede l'analisi di quattro ticket relativi a quattro diversi malfunzionamenti che, a prima vista sembrano simili se non identici. Dopo aver dato un'occhiata allo scenario e alla topologia (rete e indirizzamento) passiamo alla lettura dei ticket.

• Attenzione(1): se non erro l'ordine dei ticket può cambiare ad ogni caricamento della pagina.
• Attenzione(2): i quattro ticket corrispondono a quattro scenari differenti, nel senso che l'apertura di un ticket apporterà delle modifiche alle configurazioni dei router che potrebbero non essere presenti all'apertura di altri ticket.
• Attenzione(3): un'ultima nota su questo laboratorio: noterete che non ho mai utilizzato il classico comando "show running-config"; mi pare di capire infatti che questo comando verrà disabilitato durante l'esame.

Contenuti

• Ticket 1 (soluzione)
• Ticket 2 (soluzione)
• Ticket 3 (soluzione)
• Ticket 4 (soluzione)

Ticket 1

Il primo ticket riporta che il Client1 non riesce a raggiungere (ping) l'indirizzo 209.65.200.241 che appartiene al Web Server Internet. Apriamo quindi Client1 ed eseguiamo:
 C:\>tracert 209.65.200.241
Notiamo che tutte le richieste vanno in timeout. Controlliamo quindi la configurazione di rete del Client1:

C:\>ipconfig

E verifichiamo che il gateway è impostato correttamente (172.16.2.1). Controlliamone la raggiungibilità:

C:\>ping 172.16.2.1

E verifichiamo che il Client1 non è in grado di raggiungere il suo default gateway. Analizzando il documento relativo alla topologia fisica apprendiamo che Client1 è collegato allo switch ASW1 che a sua volta è collegato in trunk allo switch DSW1. Controlliamo quindi lo switch ASW1:

ASW1#show interfaces fa 1/0/1
ASW1#show vlan id 10

Notiamo quindi che l'interfaccia è attiva e configurata nella vlan corretta; controlliamo quindi il trunk tra i due switch:

ASW1#show interfaces trunk
DSW1#show interfaces trunk

Vediamo quindi che lo switch ASW1 permette il transito delle vlan 10 e 98 attraverso il trunk, ma lo switch DSW1 non permette il transito della vlan 10 che è quella dove risiede PC1.

Ticket 1 (Soluzione)

Il problema risiede quindi sullo switch DSW1 relativamente alla connettività inter-switch. In particolare occorre aggiungere la vlan 10 sull'interfaccia fa 1/0/19:

switchport trunk allowed vlan 10,98

Ticket 2

Il secondo ticket riporta che il Client1 non riesce ancora a raggiungere (ping) l'indirizzo 209.65.200.241 che appartiene al Web Server Internet. Apriamo quindi Client1 ed eseguiamo nuovamente:

C:\>tracert 209.65.200.241

Vediamo che l'ultimo hop raggiunto è R1 (172.16.1.1). Apriamo quindi R1 e proviamo da qui a raggiungere il Web Server:

R1#ping 209.65.200.241

Notiamo che neanche R1 riesce a raggiungere il Web Server. Controlliamo quindi la tabella di routing:

R1#show ip route

E scopriamo che esiste un default gateway che esce per l'interfaccia Serial0/0/0. Verifichiamo lo stato delle interfaccie:

R1#show ip interface brief

Ci accorgiamo che l'interfaccia verso internet è la Serial0/0/1 e non la Serial0/0/0.

Ticket 2 (Soluzione)

Il problema risiede quindi sul router R1 relativamente al routing statico. In particolare occorre eliminare il precedente default gateway e aggiungere quello corretto:

no ip route 0.0.0.0 0.0.0.0 Serial0/0/0 209.65.200.226
ip route 0.0.0.0 0.0.0.0 Serial0/0/1 209.65.200.226

Ticket 3

Il terzo ticket riporta (ancora) che il Client1 non riesce a raggiungere (ping) l'indirizzo 209.65.200.241 che appartiene al Web Server Internet. Apriamo quindi Client1 ed eseguiamo nuovamente:

C:\>tracert 209.65.200.241

Questa volta l'ultimo hop raggiungibile è DSW1 (172.16.2.1); notiamo che in questo ticket troviamo un problema che nel ticket precedente non era presente. A questo mi riferisco quando sostengo che i diversi ticket vanno trattati singolarmente. Colleghiamoci su DSW1 e verifichiamo la tabella di routing:

DSW1#show ip route

Notiamo immediatamente che non è presente alcuna rotta EIGRP ed è presente una sola rete connessa (172.16.2.0) quando dovrebbero essere due; probabilmente la connettività della rete 172.16.1.12 ha qualche problema.

DSW1#show ip interface brief

Notiamo che l'interfaccia FastEthernet1/0/1 ha configurato l'IP 172.16.1.14 (nello schema era riportata l'interfaccia FastEthernet1/0/4 ma supponiamo sia stata una svista); tale interfaccia risulta attiva ma senza link. Verifichiamo quindi lo stato di R4.

R4#show ip interface brief

Vediamo immediatamente che l'interfaccia FastEthernet0/0 è in shutdown, tale interfaccia è quella che collega lo switch DSW1.

Ticket 3 (Soluzione)

Il problema risiede quindi sul router R4 relativamente all'interfaccia FastEthernet0/0. In particolare occorre attivare tale interfiaccia:

no shutdown

Ticket 4

Il quarto e ultimo ticket riporta (ancora) che il Client1 non riesce a raggiungere (ping) l'indirizzo 209.65.200.241 che appartiene al Web Server Internet. Apriamo quindi Client1 ed eseguiamo nuovamente:

C:\>tracert 209.65.200.241

L'ultimo hop raggiungibile è ancora DSW1 (172.16.2.1). Colleghiamoci su DSW1 e verifichiamo la tabella di routing:

DSW1#show ip route

Notiamo che sono presenti alcune rotte EIGRP ma non è impostato il default gateway. Tale gateway dovrebbe essere distribuito dal router R1 che è direttamente connesso a internet. Notiamo anche che non è presente la rotta EIGRP relativa alla rete 172.16.1.0, che connette R1 con R2. Possiamo ipotizzare una errata configurazione di EIGRP nel router R1 o R2. Controlliamo per prima cosa la tabella di routing di R1 e lo stato del protocollo EIGRP.

R1#show ip route
R1#show ip protocols
R1#show ip eigrp neighbors

Grazie al primo comando possiamo verificare la presenza di un default gateway, mentre il secondo comando ci informa che EIGRP redistribuisce le rotte statiche e quindi il default gateway. Il terzo comando ci fa notare che R1 non ha alcun neighbor, mentre ci aspettavamo di vedere R2. Controlliamo quindi lo stato di EIGRP nel router R2.

R2#show ip protocols

Notiamo che tutte le interfacce presenti sono configurate come passive, la causa più probabile è che sia stato dato il comando "passive-interface default"

Ticket 4 (Soluzione)

Il problema risiede quindi sul router R2 relativamente alla configurazione di EIGRP. In particolare deve essere rimosso il comando che imposta tutte le interfacce in passive:

no passive-interface default