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.

  1. Observar
  2. Forma unha hipótese
  3. Proba a hipótese
  4. Análise de resultados
  5. Implementar unha corrección
  6. Comprobar

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

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)?
No
Problema: Sistema operativo / problema de software
Si
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:

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)

Proceso de diagnóstico

  1. Ping test:
  2. Test de Bandwidth (iperf):
  3. Packet captura:
  4. 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)

Diagnostic Process

  1. Interface de inspección:
  2. Erros de conta:
  3. 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)

Diagnostic Process

  1. Resolución DNS:
  2. Ping test:
  3. Pequena solicitude HTTP (curl):
  4. Gran descarga:
  5. MTU Test:ping -M do -s 1472ping -M do -s 1473
  6. 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)

Diagnostic Process

  1. Proba de Bandwidth:
  2. Inspección QoS:
  3. Inspección de cola:
  4. 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:

Para a escalada:

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

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

Durante a resolución de problemas

Despois da resolución

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