El problema:
La solució:
El cost del problema Haphazard:
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ó:
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:
Quan usar:
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:
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:
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:
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 1472ping -M do -s 1473El 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:
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:
| 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:
Actualitzada: 2 de febrer de 2026 Autor del Author: Baud9600 Team tècnics