Troubleshooting L2/L3: show, logs, ping, extended ping, traceroute y capturas (2.4)

📋 En esta lección

Cierre del módulo de switching: el flujo completo de diagnóstico cuando "algo no llega", integrando todas las herramientas — la secuencia de show de capa 2, la lectura de logs, el ping extendido con origen forzado, el traceroute interpretado a fondo y las capturas de tráfico con SPAN. Con un caso guiado de principio a fin, como caerá en el examen y en tu primer día malo de producción.

El flujo: de la capa 1 hacia arriba

A estas alturas del curso tienes todas las piezas; lo que falta es el orden. Cuando el usuario de la VLAN 10 "no llega" al servidor de la VLAN 30, la secuencia disciplinada es:

1. FÍSICO      show interfaces status / show interfaces X      (lección 2.4)
2. VLAN        show vlan brief · show interfaces X switchport  (5.1)
3. TRUNK       show interfaces trunk (allowed→active→forwarding) (5.2)
4. STP         show spanning-tree vlan N                       (5.8)
5. MAC         show mac address-table [address|interface]      (2.3)
6. GATEWAY/L3  show ip interface brief · show ip route · show arp (4.5, 5.3)
7. EXTREMO A EXTREMO  ping / extended ping / traceroute

Cada escalón usa el resultado del anterior: no saltes — el 80% de los diagnósticos eternos son gente buscando en capa 3 un problema de capa 2.

Los logs: el switch te lo está contando

Antes incluso del primer show, mira lo que el dispositivo ya dijo:

SW1# show logging | include LINK|SPANTREE|CDP|PM-4|ERR
%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to down
%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Gi0/10 on VLAN0010
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on Gi0/24
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/7

Cada uno de esos mensajes es una lección de este curso señalándote con el dedo: un flapping de enlace, un root guard actuando, un native mismatch, un BPDU guard disparado. El formato (%FACILITY-SEVERIDAD-MNEMONIC) y la gestión centralizada de logs se estudian en la lección 8.5 — aquí la costumbre que importa: show logging es el segundo comando de todo diagnóstico (el primero es el show del síntoma).

Para verlos en vivo durante una sesión SSH: terminal monitor (y terminal no monitor al acabar).

Extended ping: preguntas con matiz

El ping normal responde "¿llego?". El extended ping (Privileged EXEC, ping sin argumentos) responde preguntas mejores:

R1# ping
Protocol [ip]:
Target IP address: 10.5.30.10
Repeat count [5]: 500
Datagram size [100]:
Extended commands [n]: y
Source address or interface: GigabitEthernet0/0/0.10
Type of service [0]:
Set DF bit in IP header? [no]:
...

Los tres usos que resuelven averías reales:

• Origen forzado (Source address): el ping normal sale con la IP de la interfaz de salida. Forzando como origen la subinterfaz de la VLAN 10 verificas el camino de vuelta: que el servidor (y todos los routers intermedios) saben volver a la subred de usuarios, no solo al enlace del router. La mitad de los "el ping funciona desde el router pero no desde el PC" son exactamente esto.
• Repeticiones altas (Repeat count 500): un enlace que pierde el 2% no falla nunca en 5 pings. En 500, verás Success rate is 98 percent — la pérdida intermitente queda cuantificada.
• Tamaño + DF bit: con Datagram size 1500 y Set DF bit yes detectas problemas de MTU en el camino (un túnel que fragmenta, un enlace mal configurado): el ping grande muere donde el pequeño pasa.

Traceroute: leer cada línea

R1# traceroute 10.9.30.10
  1 10.255.255.2      1 msec  1 msec  1 msec
  2 10.255.255.10     4 msec  3 msec  4 msec
  3  *  *  *
  4  *  *  *

Interpretación profesional:

• La avería está después del último salto que responde: el salto 2 contesta, el 3 no — el problema vive entre el router del salto 2 y el siguiente. Ahí es donde conectas por SSH a mirar rutas.
• Un * aislado en un salto que luego sigue no es fallo: muchos routers limitan (rate-limit) sus respuestas ICMP TTL-exceeded o las filtran. Si los saltos posteriores responden, el camino funciona.
• * hasta el final pero el ping al destino funciona: el destino filtra ICMP de traceroute pero no echo — molesto, no roto.
• En Windows es tracert (usa ICMP); IOS y Linux usan UDP por defecto — por eso a veces dan resultados distintos con firewalls de por medio.

Capturas: ver las tramas de verdad

Cuando los show no bastan ("el DHCP no llega y todo parece bien"), toca ver el tráfico real. En un switch, el tráfico de un puerto no pasa por los demás (lección 2.3) — para capturarlo existe SPAN (port mirroring): copia el tráfico de un puerto/VLAN hacia el puerto donde tienes el analizador (Wireshark):

SW1(config)# monitor session 1 source interface Fa0/5 both
SW1(config)# monitor session 1 destination interface Fa0/24
SW1# show monitor session 1

Todo lo que entra y sale por Fa0/5 se copia a Fa0/24. Con Wireshark allí ves la conversación real: ¿el DHCP Discover del PC llega al switch? ¿Sale el Offer de vuelta? La respuesta corta el problema por la mitad con certeza absoluta — la trama está o no está.

En el examen, SPAN aparece a nivel conceptual: qué es, para qué sirve, source vs destination. En la práctica: úsalo con moderación (duplica tráfico) y desmonta la sesión al acabar (no monitor session 1).

Caso guiado: "no llego al servidor"

Síntoma: PC-A (10.5.10.50, VLAN 10, en SW2) no alcanza al servidor 10.5.30.10 (VLAN 30, en SW1). Ayer funcionaba.

1. ¿Qué funciona y qué no? PC-A hace ping a su gateway (10.5.10.1): OK. Al servidor: timeout. Otros usuarios de la VLAN 10: mismo problema. → El fallo es común a la VLAN, entre el gateway y el servidor. La capa física de PC-A queda descartada sin tocar un cable.

2. Logs del switch del servidor (SW1):

%LINK-3-UPDOWN: Interface Gi0/13, changed state to up
%PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/13

Ahí está la historia: el puerto del servidor se levantó (¿alguien lo desconectó y reconectó?) y port security lo tumbó por violación.

3. Confirmar: show interfaces status err-disabled → Gi0/13, causa psecure-violation. show port-security interface Gi0/13 → última MAC vista ≠ la sticky guardada.

4. Causa raíz: mantenimiento nocturno — cambiaron la NIC del servidor; la MAC nueva viola la sticky antigua.

5. Arreglo: borrar la MAC sticky obsoleta, shutdown / no shutdown, verificar up/up, ping de PC-A al servidor: OK. 6. Prevenir: procedimiento de mantenimiento que incluya avisar a red de cambios de hardware.

Fíjate en la economía: dos comandos de lectura (ping dirigido + logs) señalaron el punto exacto. El método hace el trabajo.

Relación con otros conceptos

• Esta lección orquesta todo el módulo: la secuencia L2 (5.1-5.9) más el diagnóstico IP del Módulo 4 — es el examen 2.4 en estado puro.
• Los mensajes de log que aquí lees por encima se sistematizan con syslog en la lección 8.5 (severidades, servidor central).
• El extended ping con origen forzado será tu herramienta favorita al verificar OSPF y rutas estáticas en el Módulo 7.
• La metodología general (aislar, hipótesis única, causa raíz, prevención) se formaliza en la lección 12.1 y se entrena en los labs del 12.2.

Resumen

El diagnóstico L2/L3 es una escalera fija: físico → VLAN → trunk → STP → tabla MAC → gateway/rutas → extremo a extremo, con show logging como segundo comando siempre (los logs suelen contener la respuesta: err-disable, root guard, native mismatch, flapping). Extended ping añade lo que el normal no puede: origen forzado (verifica el camino de vuelta), cientos de repeticiones (cuantifica pérdida intermitente) y tamaño+DF (caza MTU). Traceroute: la avería vive tras el último salto que responde; los * sueltos con saltos posteriores vivos son rate-limiting, no fallo. Y cuando los show no deciden, SPAN + Wireshark enseñan la trama real. Método sobre intuición, un cambio cada vez, y causa raíz siempre.

Fuentes oficiales

• Cisco — Troubleshoot Switch Port and Interface Problems
• Cisco — Configure Catalyst Switched Port Analyzer (SPAN)