El problema: Una aplicación de bases de datos es "bajo". El equipo de red culpa al equipo del servidor. El equipo del servidor culpa a la red. Mientras tanto, los usuarios están frustrados, y las horas se desperdician en depuración circular.
La solución: Un enfoque sistemático y científico de la solución de problemas que utiliza pruebas, no hipótesis, para identificar causas profundas.
El costo de la solución de problemas de Haphazard: Tiempo desperdiciado, correcciones incorrectas que enmascaran problemas reales, punción de dedos entre equipos y experiencia de usuario degradada.
La solución de problemas de red es fundamentalmente un ejercicio en el método científico:
Este artículo proporciona un marco estructurado para la solución de problemas de red que previene errores comunes como:
Antes de sumergirse en el diagnóstico técnico, responda a estas cinco preguntas críticas para reducir su alcance de investigación:
¿Cambios de configuración? ¿Nuevo hardware? ¿Actualizaciones de software? ¿Cambiaciones de topología?
¿Un usuario? ¿Un edificio? ¿Todos? ¿Sólo aplicación específica?
¿Sucede todo el tiempo? ¿Sólo durante ciertas horas? ¿Sucesiones aleatorias?
¿Puede desencadenar el problema bajo demanda?
Compruebe ambos extremos de la conexión
El modelo OSI proporciona un marco estructurado para la solución de problemas. Trabajar desde Layer 1 (Physical) hacia arriba, o desde Layer 7 (Aplicación) hacia abajo, dependiendo de los síntomas.
Cuándo utilizar: Pérdida de conectividad completa, sin luz de enlace o síntomas de capa física
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, captura de paquetesnslookup, dig, curl -vCuándo utilizar: Problemas específicos para aplicaciones donde existe conectividad básica
Iniciar en Layer 7 (¿Está funcionando el servicio SharePoint? DNS resolviendo para corregir IP?) y trabajar sólo si es necesario.
Utilice este árbol de diagnóstico rápido para identificar qué capa está fallando:
La pila TCP/IP no funciona. Consulta los servicios del sistema operativo, reinstalar los controladores de red.
NIC discapacitado, conductor equivocado, cable descompuesto. Check: ip link show o Administrador de dispositivos
Comprobación: Cable físico, estado del puerto de conmutación, asignación VLAN, tabla ARP
Control: Mesa de enrutamiento, reglas de cortafuegos, LCA. Uso traceroute para encontrar dónde paran los paquetes
Compruebe: configuración del servidor DNS, disponibilidad del servidor DNS, puerto de bloqueo de firewall 53
Check: Reglas de cortafuegos, grupos de seguridad, servicio de escucha en puerto
El problema es con la aplicación misma, autenticación o configuración de aplicaciones
Cuando usted tiene una hipótesis sobre la causa raíz, utilice estas técnicas de aislamiento para confirmar o rechazarla:
Capturar el tráfico en fuente, puntos intermedios y destino para identificar dónde se bajan o modifican los paquetes:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
Eliminar las variables externas mediante pruebas de conectividad dentro de un solo dispositivo:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
Compare la configuración y el comportamiento contra un sistema de trabajo:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
La documentación adecuada evita la depuración circular donde intentas lo mismo varias veces sin realizarla.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
Tiempos de respuesta de la aplicación de la base de datos degradados de 100m a 5 segundos. El equipo de aplicación culpó a "latría de red".
Los búferes OS del servidor de bases de datos eran demasiado pequeños para el producto de retraso de banda alta ×. La ventana TCP se llenaría, obligando al remitente a esperar.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
No asuma: "Despacio" no siempre significa "latencia de red". Reúne siempre evidencia (esperando, captura de paquetes para comportamiento) antes de saltar a conclusiones.
La conexión del servidor caería al azar, especialmente bajo carga. A veces funcionaba bien, a veces completamente poco responsable.
La negación automática falló. Servidor negociado de dúplex completo, cambio cayó de nuevo a medio dúplex. Las colisiones sólo se produjeron bajo carga cuando ambos lados intentaron transmitir simultáneamente.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Compruebe ambos extremos: El estado de la interfaz muestra los ajustes negociados. Un desajuste significa que la negación automática falló. Velocidad/duplex siempre de código duro para servidores.
Los usuarios pueden navegar por algunos sitios web (Google, Yahoo) pero no otros (sitio bancario, portal de la empresa). Pequeñas solicitudes HTTP funcionadas, páginas grandes cronometradas.
ping -M do -s 1472 tiene éxito, ping -M do -s 1473 fallasEl túnel VPN redujo la MTU a 1400, pero el cortafuegos bloqueaba los mensajes de la ICMP "Fragmentation Needed". Path MTU Discovery (PMTUD) no podía funcionar, creando un agujero negro MTU. Pequeños paquetes en forma, grandes paquetes con conjunto de bits DF fueron silenciosamente caídos.
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Cuestiones de tamaño: Si las solicitudes pequeñas funcionan pero las transferencias grandes fracasan, se sospechan problemas de MTU/fragmentación. Use ping con bit DF para probar la ruta MTU.
Las llamadas de voz tenían audio choppy, deserciones intermitentes. Sólo ocurrió durante las horas de trabajo (9am-5pm).
La política de QoS existió pero la asignación de ancho de banda fue atrasada: el mejor esfuerzo obtuvo el 60%, la voz obtuvo el 5%. Durante las horas de negocio cuando el tráfico de datos aumentó, los paquetes de voz se retiraron debido a la sobrefluencia de cola.
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Cuestiones basadas en el tiempo = capacidad: Si los problemas sólo ocurren durante horas ocupadas, no es un fallo difícil, sino un problema de capacidad/QoS. Consulta estadísticas de cola, no sólo ancho de banda total.
| Síntoma | Layer | Comandos para correr | Qué buscar |
|---|---|---|---|
| No hay luz de enlace | Capa 1 | show interfaces |
Estado: abajo, sin portador, sin cable |
| Pérdida de paquete | Capa 1/2 | show interfaces |
Errores de CRC, runtas, gigantes, colisiones, colisiones tardías |
| No puedo abrir la puerta. | Capa 2 | arp -a |
No entrada ARP, MAC no aprendió, bloqueo STP |
| No se puede llegar a la subred remota | Capa 3 | traceroute |
Desapareciendo la ruta, mal al lado, lazo de enrutamiento |
| Conexión rechazada | Capa 4 | telnet host port |
Servicio de no escuchar, bloque de cortafuegos, TCP RST |
| Rendimiento lento | Capa 4+ | ping (RTT) |
Latencia alta, límite ancho de banda, retransmisiones TCP, cero ventanas |
| No puedo resolver el nombre de host | Capa 7 | nslookup |
DNS server unreachable, wrong DNS config, NXDOMAIN |
| Caídas intermitentes | Layer 1/2 | ping -f (flood) |
Desigualdad dúplex, cable fallido, reconvergencia STP |
| Funciona a veces, no a otros | múltiple | Extended ping |
Cuestiones de equilibrio de carga, asimetría ECMP, flujo de mesa estatal |
Saber cuándo escalar a proveedores TAC o ingenieros senior. Escalar cuando:
Cada sesión de solución de problemas es una oportunidad de aprendizaje. Construir una base de conocimiento personal:
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
Organizar comandos frecuentemente utilizados por escenario para una referencia rápida durante la solución de problemas.
Cambiar configuraciones sin entender el problema a menudo empeora las cosas o enmascara el problema real.
A menudo "problemas de red" son problemas de aplicación, servidor o cliente. Reunir evidencia antes de aceptar la culpa.
Usted perderá tiempo repitiendo pruebas que ya ha hecho, o no puede explicar a los colegas lo que ha intentado.
Los problemas intermitentes son a menudo signos de alerta temprana de fracaso inminente. Investigarlos antes de que se vuelvan críticos.
Reiniciar un dispositivo puede restaurar el servicio, pero si usted no descubre por qué necesitaba reiniciar, el problema se repetirá.
La solución de problemas de red es ciencia y arte. La ciencia está siguiendo una metodología sistemática, utilizando correctamente las herramientas de diagnóstico y entendiendo protocolos. El arte es saber qué pruebas para ejecutar primero basado en síntomas, reconociendo patrones de experiencia y sabiendo cuándo escalar.
Al seguir el enfoque sistemático esbozado en este artículo, haciendo las preguntas correctas, trabajando metódicamente a través del modelo OSI, documentando sus pasos y aprendiendo de cada tema, se volverá más eficiente en la solución de problemas y evitar los obstáculos comunes que conducen a perder tiempo y corregir incorrectamente.
Recuerda: El objetivo no es sólo restaurar el servicio, sino entender por qué falló para evitar que vuelva a suceder.
Última actualización: 2 de febrero de 2026 Silencio Autor: Baud9600 Equipo Técnico