Network Troubleshooting Methodology - The Systematic Approach

Tamén dispoñible en:

Metodoloxía de resolución de problemas: o enfoque sistemático

Por que a metodoloxía importa

O problema:

A solución:

Custo de resolución de problemas:

Introdución ao método científico aplicado á rede

A resolución de problemas de rede é fundamentalmente un exercicio do método científico.

Observar
Forma unha hipótese
Proba a hipótese
Análise de resultados
Implementar unha corrección
Comprobar

Este artigo proporciona un marco estruturado para resolución de problemas de rede que evita caídas comúns como:

Nesgo de confirmación (só para probas que apoien a túa suposición inicial)
Cambios aleatorios sen diagnóstico (o enfoque de oración e oración)
Fixar os síntomas en lugar das causas
Debuxar circular sen documentar o que foi probado.

As cinco preguntas clave

Antes de someterse ao diagnóstico técnico, responda a estas cinco preguntas críticas para reducir o alcance da investigación.

Pregunta 1: Que cambiou?

Comprobar os rexistros de xestión de cambios
Revisión de erros recentes nos sistemas de xestión de configuración
Pregunta: ¿Funcionou onte?

Pregunta 2: A quen lle importa?

Un dispositivo: NIC, cable, configuración
Unha subnet: Gateway, DHCP ou cuestión de cambio
Todos: Infraestruturas básicas, ISP ou problemas xeneralizados
App específica: Servidor de aplicacións, firewall ou DNS

↓

Pregunta 3: ¿É constante ou non?

Constante: Fracaso duro (corteable, mal configuración, servizo para abaixo)
Baseado no tempo: Conxestión en horario de traballo, procesos programados
Rexión/Random: Desarrollo de dúplex, falta de hardware, ligazón intermitente

↓

Pregunta 4: Poderías reproducila?

Si: Máis fácil de diagnosticar (pódese probar hipóteses)
No: Configurar o seguimento / rexistro e esperar a recorrencia

↓

Pregunta 5: ¿Que pensas do outro lado?

Perspectiva de cliente vs. servidor
Captura de paquetes en Source vs. Destino
Enrutamento asimétrico? Distintos camiños para enviar vs. recibir?

Enfoque diagnóstico baseado no modelo OSI

O modelo OSI proporciona un marco estruturado para solucionar problemas. Traballar desde a capa 1 (física) cara arriba, ou desde a capa 7 (aplicación) cara abaixo, dependendo dos síntomas.

Aproximación de Bottom-Up (Layer 1 → Layer 7)

Cando usar:

Unidade 1: Física

↓

Tema 2: Enlace de datos

↓

Módulo 3: Rede

↓

Módulo 4: Transporte

↓

Layer 5-7: Sesión/Presentación

Aproximación de arriba (Layer 7 → Capa 1)

Cando usar:

Exemplo:

Comeza na Capa 7 (funciona o servizo de SharePoint? DNS para corrixir IP?) e traballar só se é necesario.

A árbore de decisións é 1, 2 ou 3?

Use esta árbore de diagnóstico rápido para identificar que capa está fallando:

Pode ping localhost (127.0.0.1)?

Problema: Sistema operativo / problema de software

Poderías engadir o teu propio enderezo IP?

↓ NO

Layer 1/2 - Interface de rede local

↓ YES

Pode pasar a pasarela por defecto?

↓ NO

Capa 1/2 - Rede local

↓ YES

Pódese acceder a un servidor remoto por enderezo IP?

↓ NO

Categoría: Layer 3 - Routing

↓ YES

¿Podes configurar DNS (nome do servidor)?

↓ NO

Categoría: DNS Configuration

↓ YES

¿Podes acceder ao porto de acollida de Telnet?

↓ NO

Comentarios en Firewall / Port Blocking

↓ YES

A rede está OK - Application Layer Issue

Técnicas de illamento

Cando teña unha hipótese sobre a causa raíz, use estas técnicas de illamento para confirmala ou rexeitala:

Substitución de compoñentes sistemáticamente

Tip:

Cable con cable coñecido
Proba en diferentes portos
NIC (ou adaptador de rede USB)
Proba de diferentes dispositivos cliente
VLAN / Subnet

Capturas de envases en varios puntos

Captura de tráfico en orixe, puntos intermedios e destino para identificar onde se lanzan ou modifican os 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

Probas de Loopback

Eliminar variables externas probando a conectividade nun só 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

Comparacións Base Boa

Comparar configuración e comportamento contra un sistema de traballo:

# 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")

Documentación durante a resolución de problemas

A documentación adecuada impide a depuración circular onde se intenta facer o mesmo varias veces sen darse conta.

Troubleshooting Template

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

Por que a documentación importa:

Real-World Case Studies

Case Study 1: "A rede é lenta" (en realidade, o esgotamento da fiestra TCP)

Symptom

Os tempos de resposta á base de datos son degradados de <100ms a 5 segundos. O equipo de aplicacións culpou a " latencia de rede".

Avaliación inicial (Wrong)

Conxestión de rede
Conexión saturada
Firewall bottleneck

Proceso de diagnóstico

Ping test:
Test de Bandwidth (iperf):
Packet captura:
Inspección do servidor:

Raíz causa

Os tampóns do servidor de bases de datos OS eran demasiado pequenos para o produto de retardo × ancho de banda alto. A xanela TCP enchería, obrigando ao emisor a esperar.

Resolución

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

Lección aprendida

Non asumas:

Estudo do caso 2: Conectividade intermitente (en realidade: falta de Duplex)

Symptom

A conexión do servidor cae aleatoriamente, especialmente baixo carga. Ás veces funcionaba ben, ás veces sen resposta.

Initial Assumptions (Wrong)

Fracaso NIC
Mal cable
Cambio de hardware

Diagnostic Process

Interface de inspección:
Erros de conta:
Caídas tardías:

Root Cause

A autogoberno fracasou. Servidor negociado full-duplex, o interruptor volveu a medio-duplex. As colisións só se produciron cando ambos os lados tentaron transmitir simultaneamente.

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

Comprobe os dous extremos:

Case Study 3: "Non pode chegar a algúns sitios web" (en realidade, o burato negro MTU / PMTUD)

Symptom

Os usuarios poden navegar por algúns sitios web (Google, Yahoo) pero non por outros (páxina web da compañía). As pequenas solicitudes HTTP funcionaron, as grandes páxinas foron eliminadas.

Initial Assumptions (Wrong)

problema DNS
Firewall bloqueo de sitios específicos
Problema de enrutamento ISP

Diagnostic Process

Resolución DNS:
Ping test:
Pequena solicitude HTTP (curl):
Gran descarga:
MTU Test:ping -M do -s 1472ping -M do -s 1473
Monitorización ICMP:

Root Cause

O túnel VPN reducía MTU a 1400, pero o firewall bloqueaba as mensaxes "Fragmentation Needed". Path MTU Discovery (PMTUD) non podía funcionar, creando un buraco negro MTU. Pequenos paquetes encaixan, grandes paquetes con conxunto de bits DF foron eliminados silenciosamente.

Resolution

! 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

Lesson Learned

Tamaños importantes:

Estudo de caso 4: cuestións de calidade VoIP (en realidade: mal configuración QoS)

Symptom

As chamadas de voz tiñan son choppy, saltos intermitentes. Só ocorreu durante o horario de traballo (9 a 5 horas).

Initial Assumptions (Wrong)

ancho de banda insuficiente
Servidor VoIP sobrecargado
ISP calidade de conexión

Diagnostic Process

Proba de Bandwidth:
Inspección QoS:
Inspección de cola:
Packet captura:

Root Cause

A política de QoS existía pero a asignación de ancho de banda estaba cara atrás: o mellor resultado obtivo o 60%, a voz conseguiu o 5%. Durante as horas de traballo, cando o tráfico de datos aumentou, os paquetes de voz foron eliminados debido ao desbordamento de cola.

Resolution

! 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

Lesson Learned

Cuestións de tempo = capacidade:

Comentarios en Symptom

Symptom	Capa	Mando para correr	O que buscar
Sen luz de enlace	Capa 1	`show interfaces ethtool eth0`	Estado: Baixo, sen portador, cable non conectado
Packet loss	Capa 1/2	`show interfaces show interfaces counters errors`	erros CRC, runts, xigantes, colisións, colisións tardías
Non é posible pasarela	Capa 2	`arp -a show mac address-table show spanning-tree`	Sen entrada ARP, MAC non aprendido, bloqueo STP
Non se pode acceder a unha rede remota	Capa 3	`traceroute show ip route show ip route summary`	Falta de ruta, errado next-hop, enrutamento loop
Conexión rexeitada	Capa 4	`telnet host port netstat -an tcpdump`	Servizo que non escoita, firewall bloque, TCP RST
Rendemento lento	Capa 4+	`ping (RTT) iperf3 tcpdump show interfaces`	Alta latencia, límite de ancho de banda, transmisións TCP, fiestras cero
Non se pode resolver o nome do hostal	Capa 7	`nslookup dig cat /etc/resolv.conf`	Servidor DNS non dispoñible, configuración de DNS incorrecta, NXDOMAIN
Recortes intermitentes	Layer 1/2	`ping -f (flood) show logging show interfaces`	Erro de Duplex, cable en falla, reconverxencia STP
Ás veces funciona, non outras	Múltiples	`Extended ping Packet capture Interface statistics`	Problema de equilibrio de carga, asimetría do ECMP, desbordamento da mesa do estado

Cando escalada

Saber cando aumentar para o TAC ou os enxeñeiros seniores. Escalada:

Ten esgotado todos os pasos de resolución de problemas na súa base de coñecemento.
Require acceso / permisos que non ten
Problema: fallo de software do vendedor ou fallo de hardware
O impacto empresarial é crítico e sensible ao tempo.
Varios equipos deben colaborar (aplicación + rede + servidor)

Para a escalada:

Descrición do síntoma completa
Data na que comezou a cuestión
Os comandos de diagnóstico corren e a súa saída
Configuración backups
Packet captura (se é relevante)
O que xa probaches

Crea a túa base de coñecemento persoal

Cada sesión é unha oportunidade de aprendizaxe. Crear unha base de coñecemento persoal:

Crear un diario de resolución de problemas

# 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

2.Construir unha folla de comandos

Organizar ordes de uso frecuente por escenario para referencia rápida durante a resolución de problemas.

Documenta a túa rede

Diagramas de topoloxía (Layer 2 e Layer 3)
Código IP Documentación
Asignacións VLAN
Configuración estándar (modelos)
Bases de datos coñecidas (estatisticamente antes dos problemas)

Antipatróns para evitar

Non facer cambios aleatorios sen diagnóstico

Cambiar configuracións sen entender o problema a miúdo empeora as cousas ou enmascara o problema real.

# Preservativos VISA: A rede sempre ten a culpa

A miúdo os problemas de rede son problemas de aplicación, servidor ou cliente. Probar antes de aceptar a culpa.

Non: Saltar documentando os seus pasos de resolución de problemas

Perderás tempo repetindo probas que xa fixeches ou non poderás explicar aos teus colegas o que intentaches.

Non: Ignorar os problemas intermitentes

Os problemas intermitentes son frecuentemente signos de alerta temperá dun fallo inminente. Investigar antes de ser crítico.

Non: Arranxa os síntomas en lugar de causas radiculares

Restaurar un dispositivo pode restaurar o servizo, pero se non sabe por que o necesario reiniciar, o problema reaparecerá.

Resumo: Lista de revisión sistemática de problemas

Antes de comezar

As cinco preguntas máis importantes (que son?) Quen está afectado? Constante ou intermitente? Reproducible? O que o outro lado ve?
Reunir os síntomas iniciais e os informes de usuario
Comprobar os cambios ou mantemento recentes

Durante a resolución de problemas

Traballo metodicamente a través de capas OSI (bottom-up ou top-down)
Cambiar unha variable nun momento en que se proba
Cada proba e o seu resultado
Usar capturas de paquetes para ver o comportamento real do tráfico
Comparar as liñas de base coñecidas

Despois da resolución

Verifique que o problema realmente resolveu
Razón raíz e resolución
Actualizar a súa base de coñecemento
Se a configuración cambia, actualice a documentación.
Explicación: podería terse tomado isto antes?

Conclusión

A resolución de problemas de rede é tanto ciencia como arte. A ciencia segue unha metodoloxía sistemática, empregando correctamente ferramentas diagnósticas e protocolos de entendemento. A arte é saber que probas realizar primeiro baseándose nos síntomas, recoñecendo patróns da experiencia e sabendo cando escalar.

Seguindo o enfoque sistemático descrito neste artigo, facendo as preguntas correctas, traballando metodicamente a través do modelo OSI, documentando os seus pasos e aprendendo de cada cuestión, vai facer máis eficiente en resolución de problemas e evitar as trampas comúns que levan a tempo perdido e correccións incorrectas.

Lembra:

Última actualización: 2 de febreiro de 2026 | Autor: Baud9600 Equipo Técnico