Inizia con: show ip ospf neighbor su R1, poi show ip ospf interface
⭕
2. VLAN — La VLAN HR (20) non transita sul trunk
Inizia con: show interfaces trunk su SW1 e SW2
⭕
3. NAT — Nessuna traduzione verso Internet
Inizia con: show ip nat statistics, poi show run | section ip nat
⭕
4. ACL — Il traffico HTTP è bloccato per la VLAN IT
Inizia con: show ip access-lists su R1
R1-HQ#
💡 Come lavorare: usa show running-config per vedere la configurazione completa di ogni dispositivo. Poi entra in conf t per correggere. ↑↓ per la cronologia comandi, Tab per completare.
🔒
Lab PRO
Accedi al simulatore CLI interattivo con configurazioni IOS reali e 4 errori nascosti da diagnosticare.
✓ Simulatore CLI realistico✓ show run completo✓ Progress automatico
💡 Soluzione Guidata
Spiegazione completa dei 4 problemi — diagnosi, causa, fix e verifica
⚠️ Attenzione: questa sezione mostra la soluzione completa. Consigliamo di consultarla solo dopo aver tentato autonomamente la diagnosi, per massimizzare l'apprendimento.
⭕
Problema 1 — OSPF Area Mismatch
Dispositivo: R1-HQ · Protocollo: OSPF
🔍 Come si identifica
Il sintomo è che i PC della rete HQ non raggiungono la rete Branch (10.2.0.0/24) e viceversa. Il primo comando da eseguire su R1:
R1-HQ# show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface
(lista vuota — nessun neighbor)
Lista vuota = R1 e R2 non hanno mai formato l'adjacency. Il passo successivo è capire perché:
R1-HQ# show ip ospf interface serial 0/0/0
Serial0/0/0 is up, line protocol is up
Internet Address 10.0.0.1/30, Area 1 ← ERRORE! R2 usa area 0
Timer intervals configured, Hello 10, Dead 40
Confrontando con R2 (show ip ospf interface) si vede che R2 usa Area 0. R1 usa Area 1. Le aree devono corrispondere per formare l'adjacency.
🧠 Causa radice
In OSPF, due router formano un'adjacency solo se sono nella stessa area. Il comando network su R1 aveva area 1 invece di area 0. Anche un solo numero sbagliato impedisce completamente la convergenza.
✅ Fix — comandi da eseguire su R1
R1-HQ# conf t
R1-HQ(config)# router ospf 1
R1-HQ(config-router)# no network 10.0.0.0 0.0.0.3 area 1
R1-HQ(config-router)# no network 192.168.1.0 0.0.0.255 area 1
R1-HQ(config-router)# network 10.0.0.0 0.0.0.3 area 0
R1-HQ(config-router)# network 192.168.1.0 0.0.0.255 area 0
R1-HQ(config-router)# end
🔎 Verifica post-fix
R1-HQ# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL / - 00:00:37 10.0.0.2 Serial0/0/0
R1-HQ# show ip routeO 10.2.0.0/16 [110/65] via 10.0.0.2, Serial0/0/0 ← rotta appare!
⭕
Problema 2 — VLAN 20 assente dal trunk
Dispositivi: SW1-Core e SW2-Access · Layer: 2 (Data Link)
🔍 Come si identifica
I PC della VLAN 20 (HR) collegati a SW2 non riescono a pingare i server o altri dispositivi. I PC delle VLAN 10 e 30 funzionano. Questo suggerisce un problema specifico di VLAN 20.
SW2-Access# show interfaces trunk
Port Vlans allowed on trunk
Gi0/0 1,10,30 ← VLAN 20 assente!
SW1-Core# show interfaces trunk
Port Vlans allowed on trunk
Gi0/1 1,10,20,30 (verso R1 — ok)
Gi0/2 1,10,30 ← VLAN 20 mancante anche qui!
La VLAN 20 esiste su entrambi gli switch (show vlan brief la mostra come active), ma non è nella lista delle VLAN permesse sul trunk che collega SW1 e SW2.
🧠 Causa radice
Il comando switchport trunk allowed vlan era stato configurato con la lista 1,10,30 — la VLAN 20 (HR) è stata dimenticata. Le VLAN devono essere esplicitamente permesse sul trunk: se non compaiono nella lista, i frame taggati con quella VLAN vengono scartati.
✅ Fix — da eseguire su SW1 e SW2
! Su SW1-Core:
SW1-Core# conf t
SW1-Core(config)# interface GigabitEthernet0/2
SW1-Core(config-if)# switchport trunk allowed vlan add 20
SW1-Core(config-if)# end! Su SW2-Access (stesso comando):
SW2-Access# conf t
SW2-Access(config)# interface GigabitEthernet0/0
SW2-Access(config-if)# switchport trunk allowed vlan add 20
SW2-Access(config-if)# end
⚠️ Usa sempre add per aggiungere una VLAN senza rimuovere le esistenti. Senza add, il comando sostituisce l'intera lista.
🔎 Verifica post-fix
SW2-Access# show interfaces trunk
Port Vlans allowed on trunk
Gi0/0 1,10,20,30 ← VLAN 20 ora presente
⭕
Problema 3 — NAT inside mancante su Fa0/1
Dispositivo: R1-HQ · Protocollo: NAT/PAT
🔍 Come si identifica
I PC interni non riescono a navigare su Internet, anche se la route di default verso 203.0.113.1 esiste. Il ping verso 8.8.8.8 da R1 fallisce. Il primo check sul NAT:
R1-HQ# show ip nat translations
Pro Inside global Inside local Outside local Outside global
(tabella vuota — nessuna traduzione)
R1-HQ# show ip nat statistics
Outside interfaces: FastEthernet0/0
Inside interfaces:
(vuoto — nessuna interfaccia inside!)
Hits: 0 Misses: 521
Le statistiche mostrano chiaramente che nessuna interfaccia è definita come "inside". Conferma con:
R1-HQ# show run | section interface FastEthernet0/1
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip access-group 100 in
(ip nat inside MANCANTE)
🧠 Causa radice
Il NAT PAT richiede che ogni interfaccia sia marcata esplicitamente come ip nat inside (LAN) o ip nat outside (WAN). Senza ip nat inside su Fa0/1, il router non sa che i pacchetti provenienti da 192.168.1.0/24 devono essere tradotti. ip nat outside su Fa0/0 era già corretto.
✅ Fix — su R1-HQ
R1-HQ# conf t
R1-HQ(config)# interface FastEthernet0/1
R1-HQ(config-if)# ip nat inside
R1-HQ(config-if)# end
🔎 Verifica post-fix
R1-HQ# show ip nat statistics
Outside interfaces: FastEthernet0/0
Inside interfaces: FastEthernet0/1 ← ora presente!
R1-HQ# show ip nat translationstcp 203.0.113.2:1024 192.168.1.10:1024 8.8.8.8:80 8.8.8.8:80
R1-HQ# ping 8.8.8.8!!!!! ← successo
⭕
Problema 4 — ACL blocca HTTP (deny prima di permit)
Dispositivo: R1-HQ · Protocollo: ACL estesa 100
🔍 Come si identifica
Gli utenti VLAN IT riescono a connettersi via HTTPS (443) ma non HTTP (80). Il browser mostra errore di connessione sulle pagine http://. Il primo comando diagnostico:
R1-HQ# show ip access-lists
Extended IP access list 100
10 deny tcp 192.168.1.0 0.0.0.255 any eq www (5127 matches) ← BLOCCA HTTP!
20 permit tcp 192.168.1.0 0.0.0.255 any eq 443 (1124 matches)
30 permit icmp 192.168.1.0 0.0.0.255 any (248 matches)
40 deny ip any any log (0 matches)
Il contatore della riga 10 (5127 matches!) rivela che questa regola sta bloccando una quantità enorme di traffico. La riga dovrebbe essere un permit, non un deny.
🧠 Causa radice
Le ACL IOS sono elaborate in ordine sequenziale, con il primo match che vince. La riga 10 è un deny tcp eq www che blocca tutto il traffico HTTP dalla VLAN IT. La riga 20 (permit HTTPS) viene raggiunta, ma la porta 80 viene bloccata prima ancora di arrivarci. Si tratta di un errore di configurazione: deny al posto di permit.
✅ Fix — su R1-HQ
R1-HQ# conf t
R1-HQ(config)# ip access-list extended 100
R1-HQ(config-nacl)# no 10← rimuove la riga deny
R1-HQ(config-nacl)# 10 permit tcp 192.168.1.0 0.0.0.255 any eq www
R1-HQ(config-nacl)# end
💡 Con le ACL estese numerate puoi modificare una singola riga senza riscrivere tutto l'ACL. Il numero 10 identifica la riga da sostituire.
🔎 Verifica post-fix
R1-HQ# show ip access-lists
Extended IP access list 100
10 permit tcp 192.168.1.0 0.0.0.255 any eq www (2341 matches)
20 permit tcp 192.168.1.0 0.0.0.255 any eq 443 (1124 matches)
30 permit icmp 192.168.1.0 0.0.0.255 any (248 matches)
40 deny ip any any log (0 matches)
📋 Riepilogo — Metodologia applicata
OSPF — Divide & Conquer
ping fallisce → show ospf neighbor (lista vuota) → show ospf interface (area sbagliata) → fix area
VLAN — Bottom-Up
PC non si raggiungono → show vlan (esiste) → show interfaces trunk (non permessa) → fix trunk
NAT — Top-Down
Internet non raggiungibile → ping fallisce → show nat translations (vuota) → show nat statistics (no inside) → fix
ACL — Divide & Conquer
HTTP bloccato, HTTPS ok → show access-lists (contatore alto su deny) → fix riga deny → permit