El problema: Una aplicació de base de dades és lenta. L' equip de xarxa culpa a l' equip del servidor. L' equip del servidor culpa la xarxa. Mentrestant, els usuaris estan frustrats i les hores es perden en la depuració circular.
La solució: Una aproximació sistemàtica, científica per resoldre problemes que utilitzen proves, no suposicions, per identificar causes d'arrel.
El cost del problema Haphazard: Temps des de la pila de descartades, solucions incorrectes que emmascaguen problemes reals, punt de dit entre equips i experiència d' usuari degradat.
La resolució de problemes en xarxa és fonamentalment un exercici del mètode científic:
Aquest article proporciona un marc estructurat per a problemes de xarxa que impedeixen problemes comuns com ara:
Abans de ficar-se en diagnòstics tècnics, respon a aquestes cinc preguntes crítiques per tal d'aconseguir el seu àmbit d'investigació:
Canvis de configuració? Nou hardware? Actualitzacions de programari? Redaccions de Topologia?
Un usuari? Un edifici? Tothom? Només aplicació específica?
Passa tot el temps? Només durant unes hores? ocurrències aleatòries?
Pots activar el problema de petició?
Comprova els dos extrems de la connexió
El model SOI proporciona un marc estructurat per a la resolució de problemes. Feina des de la capa 1 (Phisical) cap amunt, o des de la capa 7 (Application) cap avall, depenent dels símptomes.
Quan usar: Ha perdut la connectivitat completa, sense connexió, o símptomes físics de capa
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, captura de paquetnslookup, dig, curl -vQuan usar: Problemes específics de l' aplicació on existeix la connectivitat bàsica
Comenceu a la Capa 7 (Compartint el servei aPunt? Torna a resoldre el DNS per corregir IP?) i funciona només si cal.
Useu aquest arbre de diagnòstic ràpid per identificar quina capa ha fallat:
La pila TCP/IP no funciona. Comproveu serveis OS, reinstal·leu controladors de xarxa.
Comment Comprova: ip link show o gestor de dispositius
Comprovació: cable físic, canvi d' estat del port, assignació VLAN, taula ARP
Comprovació: taula, regles de tallafocs, ACL. Ús traceroute a on s' han d' aturar els paquets
Comprova: arranjament del servidor DNS, disponibilitat del servidor DNS, port de bloqueig de tallafocs 53
Comprova: regles de tallafocs, grups de seguretat, serveis que escolten el port
El problema és amb la mateixa aplicació, autenticació o configuració de l' aplicació
Quan teniu una hipòtesi sobre la causa arrel, useu aquestes tècniques d'aïllament per confirmar o rebutjar- la:
Captura del trànsit a la font, els punts intermedis i el destí per identificar on es retiren els paquets o s' han modificat:
# 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 variables externes provant la connexió dins d' un sol dispositiu:
# 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
Compara la configuració i el comportament contra un sistema de treball:
# 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ó del Propor evita la depuració circular on intenteu la mateixa cosa múltiples vegades sense adonar- vos-en.
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
La resposta de les aplicacions de base de dades es desactualitza des de <100ms fins a 5+ segons. L'equip d'aplicació culpava "la xarxa de lateència."
Les memòries de memòria intermèdia del servidor de base de dades eren massa petites per al producte d' amplada d' alta banda × de retard. Name
# 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 assumeixis: "Slow" no sempre vol dir "lateria de la network." Sempre reuniu proves (en espera de retard, la captura de paquet per al comportament) abans de saltar a conclusions.
La connexió del servidor cauria aleatòriament, especialment sota la càrrega. De vegades va treballar bé, a vegades completament receptiu.
Ha fallat la suspensió automàtica. El servidor va negociar el full-duplex, el canvi va tornar a mitja unitat. Les col·lisions només van ocórrer sota càrrega quan tots dos costats van intentar transmetre simultàniament.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Comprova els dos extrems: Estat de la interfície mostra els paràmetres negociats. Ha fallat el desaparellació automàtica. Sempre s' han de codificar velocitat/duplex per a servidors.
Els usuaris poden navegar per alguns llocs web (Google, Yahoo) però no altres (la pàgina web de la banda, portal d' empresa). Les petites peticions HTTP han funcionat, les pàgines grans han excedit el temps.
ping -M do -s 1472 L'èxit és... ping -M do -s 1473 fallaEl túnel VPN reduït a 1400, però el tallafocs estava bloquejant els missatges ICMP de "Framentació necessària." No s'ha pogut treballar el descobriment del camí STU (TUD), creant un forat negre de l'ITU. Els paquets petits s'ajusten, els paquets grans amb DF bit s'han deixat en silenci.
! 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
Mida importa: Si les petites sol·licituds funcionen però les grans transferències fracassen, sospiten els problemes de l'UT/fament. Usa el contacte amb el DF bit per provar el camí QU.
Les trucades de veu havien tallat l'àudio, i les gotas intermitents. Només va passar durant les hores de negoci (9am-5 pm).
La política QoS va existir però l'assignació de banda va ser inversa: el millor dels drets va obtenir un 60%, la veu va tenir un 5%. Durant les hores de negoci quan s' incrementava el trànsit de dades, els paquets de veu es van deixar en passar per sobre de la cua.
! 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
Problemes basats en el temps = capacitat: Si els problemes només passen durant les hores ocupades, no és un error difícil sinó un problema de capacitat/QoS. Comprova les estadístiques de la cua, no només la banda de banda total.
| Symptom | Capa | Ordres a executar | Què cal buscar per |
|---|---|---|---|
| Sense llum d' enllaç | Capa 1 | show interfaces |
Estat: avall, sense portador, cable desconnectat |
| Ha perdut el paquet | Capa 1/2 | show interfaces |
Error CRC, executables, gegants, col· lisions finals |
| No es pot obrir la porta | Capa 2 | arp -a |
Sense entrada ARP, la MAC no ha après, bloqueig STP |
| No puc arribar a la subxarxa remota | Capa 3 | traceroute |
Falta ruta, error següent i bucle |
| S' ha refusat la connexió | Capa 4 | telnet host port |
Servei no escolta, bloc de tallafocs, TCP RST |
| rendiment lent | Capa 4+ | ping (RTT) |
Altatència, límit de banda de banda, reductors TCP, zero finestres |
| No es pot resoldre el nom de màquina | Capa 7 | nslookup |
Servidor DNS no accessible, configuració de DNS incorrecta, NXDOIN |
| Gotes intermitents | Layer 1/2 | ping -f (flood) |
Desaparellat doble cara, cables erronis, reviseu la vora |
| Funciona de vegades, no d' altres | Múltiple | Extended ping |
Problemes amb l'equilibri, l'ECMP Asimetria, el desbordament de la taula d'estat |
Saps quan s'ha d' intensificar el venedor TAC o enginyers d'alt rang. Escala quan:
Cada sessió de resolució de problemes és una oportunitat d'aprenentatge. Construeix una base de coneixement 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
Organitza les ordres usades amb freqüència per escenari de referència ràpida durant la resolució de problemes.
Canviar les configuracions sense comprendre el problema sovint fa que les coses siguin pitjors o màscares el problema real.
Sovint "temes de les xarxes" són aplicacions, servidor, o problemes amb el client. Reuneix proves abans d'acceptar la culpa.
Pots perdre el temps repetint proves que ja has fet, o ser incapaç d'explicar als companys el que has provat.
Els problemes intermitinents solen ser signes d'advertència anticipats del fracàs. Investigant-los abans de ser crític.
Reiniciar un dispositiu pot restaurar el servei, però si no trobeu per què cal reiniciar, el problema es repetirà.
Els problemes de la xarxa són la ciència i l'art. La ciència segueix una metodologia sistemàtica utilitzant eines diagnòstices correctament i entenent protocols. L'art és saber quins exàmens s'executen primer en símptomes, reconeixennt patrons d'experiència i sabent quan s'agreuja.
A continuació, el punt de vista sistemàtica d'aquest article Limónov fa referència a les preguntes correctes, al mètode de treball a través del model OSM, documentant les vostres passes, i aprendre't de cada problema, que serà més eficient per resoldre problemes i evitar els problemes comuns que porten a perdre el temps i les correccions incorrectes.
Recorda: L'objectiu no és només per restaurar el servei, sinó per entendre per què ha fallat perquè puguis impedir que torni a passar.
Actualitzada: 2 de febrer de 2026 Autor del Author: Baud9600 Team tècnics