Labs integrales de troubleshooting: escenarios completos

📋 En esta lección

Seis averías completas sobre una topología corporativa, cada una cruzando varios módulos — porque las averías reales no vienen etiquetadas con el tema al que pertenecen. Para cada escenario: el síntoma tal como te llegaría, cómo montarlo, y el diagnóstico razonado. Trabaja el escenario antes de leer la solución: leerla sin intentarlo no entrena nada.

La topología del capstone

Monta esto en Packet Tracer (o CML-Free). Es la red que has ido construyendo por partes en los labs 5.5 y 9.5, ahora completa:

                      Internet
                         │
                    [R1] Gi0/0/1 ── 203.0.113.2/30 (NAT + default)
                     │ Gi0/0/0 (trunk 802.1Q)
                [SW-DIST] (L3: SVIs, ip routing, HSRP no necesario aquí)
                  ╱        ╲            ╲
            Po1 (LACP)    Gi1/0/3      Gi1/0/5
              ╱              ╲            ╲
        [SW-ACC-1]        [WLC]         [Servidor 10.12.30.10]
         │      │            ╲
      Fa0/5   Fa0/10      [AP ligero]  ~~~ [Portátil WiFi]
      PC-A    Impresora

Configuración base: VLANs en ambos switches, trunk con native 999 y allowed acotado, EtherChannel LACP entre SW-ACC-1 y SW-DIST, ip routing y SVIs en SW-DIST, DHCP por pool para cada VLAN con exclusiones, NAT/PAT en R1, default estática en R1 y ruta por defecto de SW-DIST hacia R1.

Verifica que todo funciona antes de romper nada. Un escenario de diagnóstico partiendo de una base que ya fallaba no enseña: confunde.

Escenario 1 · "Los de administración no imprimen"

Síntoma reportado: los PCs de la VLAN 10 no alcanzan la impresora de la VLAN 40. Navegan por Internet sin problema y acceden al servidor de la VLAN 30. La impresora responde a ping desde SW-DIST.

Cómo montarlo: en la SVI de la VLAN 40, aplica una ACL extendida de entrada que permita solo la VLAN 30 hacia las impresoras, con el deny ip any any implícito cortando al resto.

💡 💡 Para antes de seguir leyendo

Escribe tu hipótesis en una línea y los dos comandos con los que la comprobarías. Después compara con el razonamiento de abajo — lo valioso no es acertar, es ver en qué paso tu razonamiento se separó del que resuelve.

Diagnóstico razonado:

1. Alcance: falla una VLAN de origen hacia un destino concreto; el resto del tráfico de esa misma VLAN funciona. Eso descarta capa física, VLAN de acceso, DHCP y gateway — si fueran el problema, nada funcionaría (12-1: acotar comparando).
2. El dato clave: SW-DIST sí alcanza la impresora. El routing entre VLANs está vivo; alguien filtra selectivamente.
3. Comprobación: show ip interface vlan 40 | include access list revela la ACL aplicada; show access-lists muestra el contador del deny creciendo con cada intento.
4. Causa raíz: la ACL permite la VLAN 30 pero no la 10 — el deny implícito (10.4) hace el resto.
5. Corrección: añadir la línea que permite a los usuarios los puertos de impresión, respetando el orden (específico antes que general) y sin tocar lo demás.

Lo que entrena: que un fallo selectivo (funciona hacia unos destinos y no hacia otros) apunta a filtrado, no a conectividad — y que los contadores de ACL señalan al culpable en segundos.

Escenario 2 · "El puesto nuevo no tiene red"

Síntoma: un puesto recién cableado en Fa0/10 no obtiene IP. El PC muestra 169.254.x.x. Los demás puestos de la planta funcionan.

Cómo montarlo: deja el puerto Fa0/10 en la VLAN 1 (sin asignarlo a la 10), como si se hubiera cableado sin configurar.

Diagnóstico razonado:

1. APIPA = la petición DHCP no obtuvo respuesta (4.2, 4.6). El problema está entre el PC y el servidor DHCP.
2. Alcance: solo este puesto → descarta el servidor DHCP y el pool (si estuvieran mal, fallaría toda la VLAN).
3. Capa 1 primero (12-1, bottom-up): show interfaces status → el puerto está connected. Hay enlace.
4. Capa 2: show vlan brief → Fa0/10 aparece bajo la VLAN 1, no la 10. Ahí está.
5. Causa raíz: puerto no asignado a su VLAN; pide DHCP en un dominio de broadcast donde no hay servidor ni relay.
6. Corrección: aplicar la plantilla de puerto de usuario completa (5.10), no solo la VLAN — switchport mode access, access vlan 10, PortFast, BPDU guard, port security.

Lo que entrena: el reflejo APIPA → VLAN del puerto, y la diferencia entre "arreglar el síntoma" (poner la VLAN) y "dejarlo bien" (aplicar la plantilla estándar).

Escenario 3 · "Desde ayer va lentísimo"

Síntoma: los usuarios de SW-ACC-1 notan lentitud general desde ayer. Ping al gateway: responde, pero con tiempos irregulares y alguna pérdida. Las transferencias grandes se arrastran.

Cómo montarlo: fuerza un desajuste de dúplex en uno de los miembros del EtherChannel — o, si tu simulador no lo permite, en el enlace SW-ACC-1 ↔ SW-DIST fija duplex half en un extremo y duplex full en el otro.

Diagnóstico razonado:

1. "Lento" no es "caído": hay conectividad, se degrada el rendimiento. Eso apunta a capa física/enlace o a saturación (12-1: definir el problema con precisión).
2. "Desde ayer" → ¿qué cambió? (12.1). Un mantenimiento, un cable sustituido, un puerto reconfigurado.
3. Los contadores (2.4): show interfaces en el camino → late collisions creciendo en un extremo y CRC en el otro, con el puerto reportando Full-duplex en el lado que miras.
4. Causa raíz: duplex mismatch (2.2). El lado half detecta colisiones tardías; el full no entiende por qué llegan tramas corruptas.
5. Corrección: misma configuración en ambos extremos — autonegociación en los dos, o valores fijos idénticos. Después, clear counters y verificar que ya no crecen.

Lo que entrena: que el síntoma "lento" tiene firma propia en los contadores, y que los contadores solo significan algo si sabes si están creciendo ahora (de ahí clear counters).

Escenario 4 · "El WiFi de invitados conecta pero no navega"

Síntoma: el portátil se asocia al SSID de invitados, pide clave, la acepta… y queda en 169.254.x.x. El SSID corporativo funciona con normalidad.

Cómo montarlo: quita la VLAN 50 de la lista allowed del trunk entre SW-DIST y el WLC.

Diagnóstico razonado:

1. Las fases de conexión (9.4): asociación y seguridad completadas (pidió y aceptó la clave) → la radio y el WLC están bien. Falla la fase siguiente: DHCP.
2. Alcance: un SSID falla y otro no → descarta AP, radio y WLC como conjunto; apunta a lo que diferencia a ambos SSIDs: su VLAN.
3. El camino de la VLAN 50 (9.2): el tráfico del cliente sale del túnel CAPWAP en el WLC y se entrega etiquetado por su trunk. show interfaces trunk en SW-DIST → la VLAN 50 no está en la lista de permitidas.
4. Causa raíz: la VLAN existe en ambos extremos, pero el trunk no la transporta: el DHCP Discover muere en el WLC.
5. Corrección: switchport trunk allowed vlan add 50 — con add, no sobrescribiendo la lista (5.2).

Lo que entrena: usar las fases de la conexión WiFi como bisturí (dónde se rompió exactamente), y la frontera entre "problema de WiFi" y "problema de red cableada" que hay detrás de la mitad de los tickets inalámbricos.

Escenario 5 · "Se cae la red entera unos segundos, varias veces al día"

Síntoma: cortes intermitentes que afectan a toda la planta, de pocos segundos, sin patrón horario claro. Entre corte y corte, todo normal.

Cómo montarlo: conecta un segundo cable entre SW-ACC-1 y SW-DIST fuera del EtherChannel (un puerto suelto en cada extremo, sin channel-group).

Diagnóstico razonado:

1. Intermitente + generalizado → topología o saturación, no configuración de un puesto (12.1).
2. Los logs primero (8.5, 12.1): show logging → mensajes %SPANTREE- de cambios de topología repetidos, y %LINK/%LINEPROTO acompañándolos.
3. La lectura: cada cambio de topología STP provoca reconvergencia; durante ella, el tráfico se interrumpe (5.7, 5.8).
4. Localizar: show spanning-tree vlan 10 detail → interfaz que reporta los cambios; show etherchannel summary → el enlace nuevo no forma parte del Po1.
5. Causa raíz: un enlace redundante añadido fuera del EtherChannel crea un camino paralelo que STP debe bloquear; la inestabilidad de ese puerto (o su interacción con el channel) dispara reconvergencias.
6. Corrección: integrarlo en el EtherChannel (channel-group 1 mode active en ambos extremos — 5-4) o retirarlo. Revisar además que los puertos de acceso llevan PortFast + BPDU guard para que ningún puesto genere TCNs (5.9).

Lo que entrena: que lo intermitente y global se diagnostica en los logs, no con pings; y por qué EtherChannel existe (dar redundancia sin bloqueos ni reconvergencias).

Escenario 6 · "No salimos a Internet, pero entre nosotros todo va bien"

Síntoma: la conectividad interna es perfecta (entre VLANs, al servidor, DNS interno). Nadie alcanza Internet. Desde R1, ping 8.8.8.8 funciona.

Cómo montarlo: modifica la ACL que selecciona el tráfico de NAT en R1 para que no incluya la subred 10.12.10.0/24 (o quita ip nat inside de la subinterfaz correspondiente).

Diagnóstico razonado:

1. Acotar: interno OK + externo KO, y R1 sí sale → el routing hasta R1 funciona y R1 tiene salida. El problema está en la traducción o en el retorno (8.3).
2. Verificación dirigida: show ip nat translations mientras un PC navega → no se crean entradas para esa subred.
3. Las dos causas posibles (8.3): las interfaces no están marcadas ip nat inside/outside, o la ACL de selección no incluye la subred. show ip nat statistics confirma qué interfaces están declaradas.
4. Causa raíz: la ACL de NAT no cubre 10.12.10.0/24 — el tráfico se enruta hasta R1, sale sin traducir con IP privada, y nunca vuelve.
5. Corrección: añadir la subred a la ACL de NAT. Verificar con show ip nat translations que aparecen entradas con puertos (PAT).

Lo que entrena: el patrón "todo funciona menos lo último que añadimos" (una VLAN nueva olvidada en la ACL de NAT es un clásico absoluto), y que el extended ping desde el router no prueba lo mismo que el tráfico de un host.

Cómo sacarle el máximo a estos labs

• Cronométrate. El objetivo realista tras el curso: diagnóstico correcto en menos de 10 minutos por escenario. En el examen tendrás menos.
• Escribe la hipótesis antes de comprobarla. Descubrirás cuántas veces "sabías" la causa y te equivocabas — y eso es aprendizaje puro.
• Haz que otro te monte la avería. Diagnosticar lo que tú mismo rompiste es entrenar con las respuestas a la vista; si estudias con alguien, intercambiad topologías rotas.
• Documenta cada uno como documentarías en producción (12.1): síntoma, alcance, causa raíz, solución, prevención. Ese cuaderno es tu mejor material de repaso final.
• Combina averías. Cuando domines las seis por separado, mete dos a la vez: es lo que ocurre en la realidad y lo que revela si tu método aguanta.

Relación con otros conceptos

• Cada escenario ataca varios módulos a la vez: ACLs (10.4/10.5), VLANs y plantillas (5.1, 5.10), dúplex (2.2/2.4), WiFi (9.2/9.4), STP y EtherChannel (5.4, 5.7/5.9), NAT (8.3), DHCP (8.1) y logs (8.5).
• El método que los resuelve todos es el de la lección 12.1; los labs previos por bloque son 5-5 y 9.5.
• La estrategia para resolver escenarios equivalentes bajo presión de reloj es la próxima lección.

Resumen

Seis averías sobre una topología corporativa completa, cada una cruzando módulos: ACL selectiva (falla un destino concreto → filtrado, no conectividad), puerto sin VLAN (APIPA en un solo puesto → show vlan brief), duplex mismatch ("lento desde ayer" → late collisions y CRC, con clear counters para saber si crecen ahora), VLAN fuera del trunk (WiFi que asocia pero no coge IP → la frontera entre problema inalámbrico y cableado), enlace redundante fuera del EtherChannel (cortes intermitentes globales → los logs de spanning tree) y subred ausente en la ACL de NAT (interno perfecto, Internet muerto → show ip nat translations vacío). Trabájalos con hipótesis escrita antes de comprobar, cronómetro en marcha, documentación al final y, cuando los domines, combinados de dos en dos.

Fuentes oficiales

• Cisco — Troubleshoot Switch Port and Interface Problems
• Cisco — Use Local and Global NAT Terms