Repaso rápido: Soporte técnico – CCNA

Lo que realmente debes saber

El soporte técnico en CCNA no significa solo conocer comandos. Significa saber afrontar un problema de red con método, evitando cambiar configuraciones al azar o saltar inmediatamente a la conclusión más cómoda.

En una red real, un problema puede depender de cables, puertos, VLAN, direcciones IP, DHCP, DNS, routing, ACL, firewalls, servicios, configuraciones erróneas o cambios recientes. Por eso el troubleshooting debe ser ordenado: identificar el problema, recopilar información, formular hipótesis, probar, aplicar una solución, verificar y documentar.

El punto central es este: un buen técnico no adivina. Observa, verifica y procede por eliminación.

Conceptos clave

• Troubleshooting: proceso estructurado para identificar y resolver un problema.
• Identificación del problema: entender qué no funciona y qué impacto tiene.
• Recopilación de información: obtener datos de usuarios, dispositivos, logs y herramientas.
• Hipótesis: posible causa del problema.
• Prueba: verificación controlada de una hipótesis.
• Verificación: confirmación de que la solución ha resuelto el problema.
• Documentación: registro de causa, solución y cambios aplicados.
• Layered approach: análisis por capas OSI/TCP-IP.
• Baseline: estado normal de la red usado como referencia.
• Change management: gestión controlada de cambios.
• Escalation: implicación de equipos o niveles superiores cuando es necesario.
• Comunicación: actualización clara hacia usuarios y stakeholders.

Diferencias que no debes confundir

Concepto	Significado principal
Síntoma	Efecto visible del problema
Causa raíz	Motivo real del problema
Hipótesis	Posible explicación que verificar
Prueba	Verificación controlada
Workaround	Solución temporal
Fix	Corrección estable
Verificación	Confirmación del restablecimiento
Documentación	Registro del trabajo realizado
Escalation	Paso a soporte superior
Baseline	Comportamiento normal esperado

Método de troubleshooting

Un método simple de troubleshooting puede seguir estos pasos:

1. identificar el problema;
2. recopilar información;
3. establecer una teoría sobre la causa probable;
4. probar la teoría;
5. crear un plan de acción;
6. aplicar la solución;
7. verificar el funcionamiento;
8. documentar problema, causa y solución.

Este método evita intervenciones aleatorias y reduce el riesgo de empeorar la situación.

En CCNA debes razonar de forma técnica pero ordenada: primero entender, luego modificar.

Identificar el problema

Antes de resolver, debes entender bien qué no funciona.

Preguntas útiles:

• ¿quién está afectado?
• ¿cuántos usuarios están afectados?
• ¿el problema afecta a un solo host o a muchos?
• ¿el problema es local o remoto?
• ¿cuándo empezó?
• ¿ocurrió después de un cambio?
• ¿el problema es continuo o intermitente?
• ¿qué servicios no funcionan?
• ¿qué sigue funcionando?

Ejemplo: “Internet no funciona” es demasiado genérico. Debes entender si es un problema DNS, gateway, Wi-Fi, DHCP, routing, firewall o solo de una aplicación.

Recopilación de información

La recopilación de información incluye datos de:

• usuarios;
• tickets;
• logs;
• configuraciones;
• comandos show;
• monitoring;
• Syslog;
• SNMP;
• ping y traceroute;
• herramientas físicas;
• documentación de red;
• cambios recientes.

Un error común es confiar solo en la descripción inicial. Los usuarios describen el síntoma, no siempre la causa técnica.

Enfoque por capas

Un enfoque muy útil es razonar por capas.

Ejemplos:

• Layer 1: cables, puertos, alimentación, señal.
• Layer 2: VLAN, MAC address, trunk, STP.
• Layer 3: IP, gateway, routing.
• Layer 4: puertos TCP/UDP, ACL, firewall.
• Layer 7: DNS, aplicaciones, servicios.

Si un host no comunica, revisar primero Layer 1 y Layer 2 puede evitar perder tiempo con routing o DNS cuando el problema es un cable desconectado.

Top-down, bottom-up y divide-and-conquer

Existen distintas formas de afrontar el troubleshooting.

Bottom-up: empiezas en Layer 1 y subes. Útil cuando sospechas problemas físicos o de conectividad básica.

Top-down: empiezas desde la aplicación y bajas. Útil cuando el problema afecta a un servicio específico.

Divide-and-conquer: empiezas desde un punto intermedio, a menudo Layer 3, y luego subes o bajas según el resultado.

Para CCNA debes saber que no existe un solo método siempre válido. La elección depende del escenario.

Baseline

Una baseline describe el comportamiento normal de la red.

Puede incluir:

• uso normal de ancho de banda;
• latencia media;
• configuraciones estándar;
• puertos normalmente activos;
• caminos de routing esperados;
• CPU y memoria de los dispositivos;
• logs normales;
• número esperado de usuarios o dispositivos.

Sin baseline es más difícil entender si un valor es normal o anómalo.

Ejemplo: una latencia de 80 ms puede ser normal en un enlace geográfico, pero anómala en una LAN.

Change management

Muchos problemas nacen después de un cambio.

Ejemplos:

• nueva VLAN;
• modificación ACL;
• actualización firmware;
• cambio gateway;
• nueva configuración DHCP;
• sustitución de switch;
• modificación trunk;
• actualización driver;
• cambio DNS.

El change management sirve para planificar, aprobar, documentar y verificar cambios.

En troubleshooting, una pregunta fundamental es: “¿Qué ha cambiado recientemente?”

Comandos show

Los comandos show son fundamentales en dispositivos Cisco.

Ejemplos útiles:

• show running-config;
• show startup-config;
• show ip interface brief;
• show interfaces;
• show vlan brief;
• show interfaces trunk;
• show mac address-table;
• show ip route;
• show arp;
• show cdp neighbors;
• show lldp neighbors;
• show access-lists;
• show logging.

Estos comandos permiten observar el estado del dispositivo sin modificar la configuración.

Debug

Los comandos debug muestran información detallada en tiempo real.

Son potentes pero deben usarse con atención.

Riesgos:

• alto consumo CPU;
• salida excesiva;
• impacto en dispositivos en producción;
• dificultad de lectura;
• riesgo de empeorar el rendimiento.

Para CCNA debes recordar que debug puede ser útil, pero debe usarse solo cuando sea necesario y con cautela, preferiblemente en ventanas controladas o entornos de laboratorio.

Ping

Ping usa ICMP para verificar alcanzabilidad.

Puede ayudar a probar:

• loopback local;
• IP del host;
• default gateway;
• destino en la misma LAN;
• destino remoto;
• pérdida de paquetes;
• latencia.

Secuencia útil:

• ping 127.0.0.1;
• ping propia IP;
• ping gateway;
• ping IP remota;
• ping nombre DNS.

Esta secuencia ayuda a entender dónde se interrumpe la comunicación.

Traceroute

Traceroute, o tracert en Windows, muestra el camino hacia un destino.

Es útil para entender:

• dónde se detiene el tráfico;
• qué routers se atraviesan;
• si el camino es coherente;
• si el problema es cercano o remoto;
• si falta una route;
• si un firewall o router no responde.

Atención: algunos dispositivos no responden a los paquetes usados por traceroute, por lo que un asterisco no significa siempre avería.

Syslog

Syslog permite recopilar mensajes de log de los dispositivos.

Puede mostrar:

• interfaces up/down;
• errores;
• logins correctos o fallidos;
• cambios de configuración;
• eventos de routing;
• violaciones ACL;
• problemas hardware;
• eventos de seguridad.

Centralizar Syslog es útil porque los logs locales pueden perderse tras reinicio o estar limitados por la memoria del dispositivo.

SNMP

SNMP permite monitorizar dispositivos de red.

Puede recoger datos como:

• estado de interfaces;
• uso de ancho de banda;
• CPU;
• memoria;
• errores;
• disponibilidad;
• temperatura;
• eventos mediante traps.

SNMP es útil para monitorización proactiva. No debes esperar a que el usuario reporte el problema: el sistema puede avisar cuando una interfaz pasa a down o se supera un umbral.

Tester de cable

Un tester de cable verifica problemas físicos en los cables.

Puede ayudar a identificar:

• cable interrumpido;
• pares invertidos;
• terminación incorrecta;
• longitud excesiva;
• cortocircuito;
• problemas de continuidad;
• cableado no conforme.

Si un puerto no sube o tiene muchos errores, un tester físico puede ser más útil que cualquier comando software.

Problemas Layer 1

Problemas comunes Layer 1:

• cable desconectado;
• cable dañado;
• puerto apagado;
• interfaz administratively down;
• módulo SFP incompatible;
• fibra sucia;
• TX/RX invertidos;
• PoE insuficiente;
• velocidad o duplex incorrectos;
• distancia máxima superada;
• errores CRC.

Síntomas típicos:

• interfaz down;
• enlace intermitente;
• muchos errores;
• throughput bajo;
• packet loss.

Problemas Layer 2

Problemas comunes Layer 2:

• VLAN errónea;
• trunk no configurado;
• VLAN no permitida en trunk;
• native VLAN mismatch;
• MAC address table errónea o inestable;
• STP blocking;
• port security violation;
• DHCP snooping mal configurado;
• DAI que bloquea ARP;
• loop Layer 2.

Comandos útiles:

• show vlan brief;
• show interfaces trunk;
• show mac address-table;
• show spanning-tree;
• show port-security;
• show interfaces status.

Problemas Layer 3

Problemas comunes Layer 3:

• IP errónea;
• subnet mask errónea;
• gateway ausente;
• route ausente;
• route de retorno ausente;
• default route errónea;
• OSPF no adyacente;
• ACL que bloquea tráfico;
• NAT no configurado correctamente.

Comandos útiles:

• show ip interface brief;
• show ip route;
• show arp;
• ping;
• traceroute;
• show access-lists;
• show ip protocols.

Troubleshooting DHCP

Problemas DHCP comunes:

• servidor DHCP no alcanzable;
• pool agotado;
• scope erróneo;
• gateway distribuido erróneo;
• DNS distribuido erróneo;
• ip helper-address ausente;
• VLAN equivocada;
• trunk erróneo;
• DHCP snooping que bloquea respuestas;
• cliente con lease antiguo.

Síntomas:

• host sin IP;
• dirección APIPA;
• IP en la subnet equivocada;
• gateway o DNS erróneos.

Troubleshooting DNS

Problemas DNS comunes:

• servidor DNS erróneo;
• registro ausente;
• registro incorrecto;
• caché DNS obsoleta;
• firewall que bloquea DNS;
• servidor DNS no alcanzable;
• DHCP que distribuye DNS erróneo.

Síntoma clásico:

• alcanzas una IP;
• no alcanzas un nombre.

En este caso el routing puede funcionar perfectamente: el problema es la resolución de nombres.

Troubleshooting routing

Problemas de routing comunes:

• route ausente;
• default route ausente;
• route de retorno ausente;
• protocolo dinámico no funcional;
• métrica o administrative distance inesperada;
• interfaz down;
• subnet no anunciada;
• ACL o firewall que bloquea tráfico.

En troubleshooting end-to-end siempre debes considerar tanto el camino de ida como el de retorno.

ACL y firewalls

ACL y firewalls pueden bloquear tráfico aunque IP y routing sean correctos.

Comprueba:

• orden de reglas;
• dirección;
• interfaz;
• deny implícito;
• puertos TCP/UDP;
• direcciones origen y destino;
• tráfico de retorno;
• logs de bloqueo.

Un error típico es permitir tráfico en una dirección pero olvidar el retorno o un servicio necesario como DNS.

Documentación

La documentación es parte del troubleshooting.

Debe incluir:

• síntoma;
• impacto;
• causa raíz;
• pruebas realizadas;
• cambios aplicados;
• solución final;
• posible workaround;
• tiempos;
• personas involucradas;
• comandos usados;
• recomendaciones futuras.

Documentar evita que el mismo problema se resuelva desde cero cada vez.

Comunicación con usuarios

El soporte técnico también requiere comunicación.

Buenas prácticas:

• hacer preguntas claras;
• no culpar al usuario;
• explicar de forma simple;
• actualizar sobre el estado;
• indicar tiempos realistas;
• confirmar la resolución;
• comunicar posibles impactos;
• documentar en el ticket.

Un buen técnico no es solo quien resuelve, sino quien mantiene claridad durante el problema.

Escalation

La escalation sirve cuando el problema supera competencias, permisos o responsabilidades del primer nivel.

Ejemplos:

• problema en equipos core;
• avería del provider;
• incidente de seguridad;
• configuración no autorizada;
• problema complejo de routing;
• necesidad de acceso administrativo;
• impacto en muchos usuarios.

Escalar no significa fallar: significa implicar el nivel correcto.

Verificación final

Después de aplicar una solución, debes verificar.

Ejemplos:

• ping funciona;
• DNS resuelve;
• usuarios confirman;
• interfaz estable;
• errores no aumentan;
• servicio alcanzable;
• logs limpios;
• routing correcto;
• ACL no bloquea tráfico legítimo.

La verificación es importante porque un problema puede parecer resuelto pero reaparecer después de pocos minutos.

Errores comunes en los quiz

• Cambiar configuración sin recopilar información.
• Saltarse Layer 1.
• Confundir síntoma y causa raíz.
• Pensar que DNS es siempre problema de Internet.
• Olvidar la route de retorno.
• Ignorar cambios recientes.
• Usar debug sin cautela.
• Olvidar el deny implícito en ACL.
• No documentar la solución.
• No verificar después del fix.
• No comunicar con el usuario.
• No escalar cuando es necesario.

Mini escenario de examen

Un usuario informa que “Internet no funciona”. El PC tiene IP correcta y puede hacer ping al gateway y a 8.8.8.8, pero no puede abrir sitios web por nombre.

El problema más probable es DNS, no conectividad general a Internet. El técnico debería verificar el servidor DNS configurado, la resolución con nslookup y la configuración DHCP.

Otro escenario: después de un cambio en una ACL, muchos usuarios ya no alcanzan un servicio. El técnico debe comprobar orden de reglas, dirección, interfaz, deny implícito y logs.

Mini checklist antes del quiz

Antes de empezar el quiz deberías saber explicar:

• las fases principales del troubleshooting;
• por qué hay que identificar bien el problema;
• qué significa causa raíz;
• cómo usar un enfoque por capas;
• cuándo usar ping y traceroute;
• para qué sirven show y debug;
• por qué Syslog y SNMP son útiles;
• cuándo usar un tester de cable;
• cómo distinguir problemas Layer 1, 2 y 3;
• cómo reconocer problemas DHCP y DNS;
• por qué ACL y firewalls pueden bloquear tráfico correcto;
• por qué documentación y comunicación forman parte del soporte técnico.