Network Troubleshooting Methodology - The Systematic Approach
Metodologia rozwiązywania problemów sieciowych: podejście systematyczne
Dlaczego Metodologia ma znaczenie
Problem: Aplikacja bazy danych jest "wolna". Zespół sieci obwinia zespół serwerów. Serwery obwiniają sieć. Tymczasem użytkownicy są sfrustrowani, a godziny marnują się w kolistym debugowaniu.
Rozwiązanie: Systematyczne, naukowe podejście do rozwiązywania problemów, które wykorzystuje dowody, a nie założenia, do określenia przyczyn pierwotnych.
Koszt rozwiązywania problemów związanych z zagrożeniami: Stracony czas, nieprawidłowe poprawki, które maskują prawdziwe problemy, wskazując palcem między zespołami, i zdegradowane doświadczenie użytkownika.
Wprowadzenie: Metoda naukowa stosowana w sieciach
Rozwiązywanie problemów sieci jest zasadniczo ćwiczeniem naukowym:
- Obserwuj objawy i zbieranie danych
- Utworzyć hipotezę o przyczynie
- Test hipotezy z narzędziami diagnostycznymi
- Analiza wyników i potwierdzić lub odrzucić hipotezę
- Wdrożenie poprawki na podstawie potwierdzonej przyczyny
- Weryfikacja problem został rozwiązany
Artykuł ten stanowi ustrukturyzowane ramy rozwiązywania problemów sieciowych, które zapobiegają częstym pułapkom, takim jak:
- Potwierdzenie uprzedzeń (szukanie tylko dowodów, które potwierdzają początkowe przypuszczenie)
- Przypadkowe zmiany bez diagnozy (podejście "spray and pray")
- Ustalanie objawów zamiast przyczyn
- Okrągłe debugowanie bez dokumentowania tego, co próbowano
Pięć kluczowych pytań
Przed nurkowaniem w diagnostyce technicznej, odpowiedz na pięć krytycznych pytań, aby zawęzić zakres śledztwa:
Zmiana konfiguracji? Nowy sprzęt? Aktualizacje oprogramowania? Zmiany topologiczne?
- Sprawdź dzienniki zarządzania zmianami
- Przegląd ostatnich zobowiązań w systemach zarządzania konfiguracją
- Zapytaj: "Czy to działało wczoraj?"
Jeden użytkownik? Jeden budynek? Wszyscy? Wyłącznie specjalny wniosek?
- Jedno urządzenie: Prawdopodobnie problem lokalny (NIC, kabel, konfiguracja)
- Jedna podsieć: Brama, DHCP lub wyłącznik
- Wszyscy: Infrastruktura bazowa, ISP lub szeroko rozpowszechniony problem
- Specjalna aplikacja: Serwer aplikacji, zasada firewalla lub DNS
Ciągle się to zdarza? Tylko w określonych godzinach? Przypadkowe zdarzenia?
- Ciągłe: Niewydolność (cięcie kabla, błędna konfiguracja, obsługa dolna)
- Czas: Zatory w godzinach pracy, procesy zaplanowane
- Okresowe / losowe: Niedopasowanie Duplex, awaria sprzętu, połączenie przerywane
Możesz uruchomić problem na żądanie?
- Tak: Dużo łatwiejsze do zdiagnozowania (można przetestować hipotezy)
- Nie: Ustaw monitorowanie / logowanie i czekaj na powtórzenie
Sprawdź oba końce połączenia
- Perspektywa klienta a perspektywa serwera
- Wychwytywanie pakietów u źródła a miejsce przeznaczenia
- Asymetryczne routing? Różne ścieżki wysyłania kontra odbierania?
Podejście diagnostyczne oparte na modelu OSI
Model OSI zapewnia ustrukturyzowane ramy rozwiązywania problemów. Przer. od warstwy 1 (fizycznej) w górę lub od warstwy 7 (aplikacji) w dół, w zależności od objawów.
Podejście Bottom- Up (Warstwa 1 → Warstwa 7)
Kiedy stosować: Kompletna utrata łączności, brak światła lub fizycznych objawów warstw
- Kontrola: Kabel podłączony? Włączyć światła? Fiber czysty?
- Polecenia:
show interfaces,ethtool eth0 - Szukaj: błędów CRC, kolizji, późnych kolizji, biegaczy, gigantów
- Sprawdź: Prawidłowe VLAN? Port włączony? Blokowanie STP?
- Polecenia:
show mac address-table,show spanning-tree - Szukaj: mapowanie, zmiany topologiczne STP, niedopasowanie VLAN
- Zaznacz: Czy możliwe jest wybranie domyślnej bramy? Stół do jazdy, zgadza się?
- Polecenia:
ping,traceroute,show ip route - Szukaj: brakujące trasy, nieprawidłowy następny hop, pętle routingu
- Sprawdź: Czy można utworzyć połączenie TCP? Firewall blokuje port?
- Polecenia:
telnet host port,netstat -an, przechwytywanie pakietów - Szukaj: retransmisje TCP, zero okien, pakiety RST
- Sprawdź: DNS rozwiązuje? Zgłoszenie? Uwierzytelnianie działa?
- Polecenia:
nslookup,dig,curl -v - Szukaj: błędy DNS, błędy aplikacji, problemy z czasem
Podejście Top- Down (Warstwa 7 → Warstwa 1)
Kiedy stosować: Problemy związane ze stosowaniem, w przypadku gdy istnieje podstawowa łączność
Start na warstwie 7 (Czy działa usługa SharePoint? DNS rozwiązuje błędy IP?) i pracuje tylko w razie potrzeby.
Drzewo decyzji: Czy to warstwa 1, 2, czy 3?
Użyj tego szybkiego drzewa diagnostycznego, aby określić, która warstwa nie działa:
Nie działa stos TCP / IP. Sprawdź usługi systemu operacyjnego, ponownie zainstaluj sterowniki sieciowe.
NIC wyłączone, zły kierowca, odłączony kabel. Sprawdź: ip link show lub menedżer urządzeń
Sprawdzanie: Kabel fizyczny, status portu przełącznika, przydział VLAN, tabela ARP
Sprawdź: Stół do jazdy, zasady firewalla, ADL. Stosowanie traceroute by znaleźć miejsce zatrzymania pakietów
Sprawdź: ustawienia serwera DNS, dostępność serwera DNS, port blokujący firewall 53
Sprawdź: Zasady Firewall, grupy ochrony, usługi słuchania na porcie
Problem tkwi w samej aplikacji, uwierzytelnianiu lub konfiguracji aplikacji
Techniki izolacji
Jeśli masz hipotezę na temat przyczyny, użyj tych technik izolacji, aby ją potwierdzić lub odrzucić:
1. Zastąp komponenty systematycznie
- Kabel Swap patch z wiedzą-dobry kabel
- Badanie na innym porcie przełącznika
- Spróbuj innego NIC (lub adaptera sieciowego USB)
- Badanie z innego urządzenia klienta
- Przenieś do różnych podsieci VLAN /
2. Uchwyty pakietów w wielu punktach
Przechwytywanie ruchu u źródła, punktów pośrednich i miejsca przeznaczenia w celu określenia, gdzie pakiety są wycofywane lub modyfikowane:
# 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
3. Testowanie pętli
Eliminacja zmiennych zewnętrznych poprzez testowanie połączeń w obrębie jednego urządzenia:
# 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
4. Known- dobre porównanie bazowe
Porównaj konfigurację i zachowanie z systemem roboczym:
# 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")
Dokumentacja podczas rozwiązywania problemów
Właściwa dokumentacja zapobiega debugowaniu w kole, gdzie próbujesz tego samego wielokrotnie, nie zdając sobie z tego sprawy.
Szablon rozwiązywania problemów
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
Real- Światowe badania przypadków
Badanie przypadku 1: "Sieć jest powolna" (Właściwie: Wyczerpanie okna TCP)
Objawy
Czas odpowiedzi aplikacji bazy danych zdegradowany z < 100ms do 5 + sekund. Zespół aplikacji obwiniał "Sieciową latencję".
Założenia początkowe (błędne)
- Zatłoczenie sieci
- Nasycone ogniwo WAN
- Zator zaporowy
Proces diagnostyczny
- Badanie Ping: RTT = 2ms (doskonała, wyklucza opóźnienie warstwy 3)
- Badanie szerokości pasma (iperf): 950 Mbps na 1 Gbps link (brak zatorów)
- Wychwytywanie pakietów: Wyświetlone pakiety TCP Zero Okna z serwera bazy danych
- Kontrola serwera: Serwer baz danych otrzymuje bufory = 64KB (małe!)
Przyczyna korzenia
Serwer baz danych bufory OS były zbyt małe dla produktów o dużej przepustowości × opóźnienie. Okno TCP wypełniłoby, zmuszając nadawcę do czekania.
Rozdzielczość
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Lekcja nauczona
Nie zakładaj: "Powolne" nie zawsze oznacza "opóźnienie sieci". Zawsze zbieraj dowody (ping za opóźnienie, przechwytywanie pakietów za zachowanie) przed wyciągnięciem pochopnych wniosków.
Studium przypadku 2: Przerwane połączenie (Właściwie: błąd Duplex)
Symptom
Połączenie z serwerem spadłoby losowo, szczególnie pod obciążeniem. Czasami działało dobrze, czasem zupełnie nie reaguje.
Initial Assumptions (Wrong)
- Niepowodzenie NIC
- Zły kabel
- Przełączanie problemu sprzętu
Diagnostic Process
- Kontrola interfejsu: Serwer NIC = 1000 / Full, przełącz port = 1000 / Half (niedopasowanie!)
- Licznik błędów: Masywna liczba zderzeń w porcie przełącznika
- Późne kolizje: Wskaźnik rozbieżności duplex
Root Cause
Auto- negocjacje zawiodły. Serwer wynegocjował full-duplex, przełącznik spadł do pół-duplex. Kolizje wystąpiły pod obciążeniem tylko wtedy, gdy obie strony próbowały transmitować jednocześnie.
Resolution
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Lesson Learned
Sprawdź oba końce: Status interfejsu pokazuje wynegocjowane ustawienia. Niedopasowanie oznacza, że negocjacje nie powiodły się. Zawsze twarda prędkość kodu / duplex dla serwerów.
Badanie przypadku 3: "Nie można osiągnąć niektórych stron internetowych" (Właściwie: MTU / PMTUD Black Hole)
Symptom
Użytkownicy mogą przeglądać niektóre strony internetowe (Google, Yahoo), ale nie inne (strona internetowa banku, portal firmy). Małe prośby HTTP działa, duże strony w czasie.
Initial Assumptions (Wrong)
- Emisja DNS
- Zapora firewall blokująca konkretne miejsca
- Problem routingu ISP
Diagnostic Process
- Rozdzielczość DNS: Działa dobrze dla wszystkich stron
- Badanie Ping: Czy ping "nieosiągalne" strony
- Małe żądanie HTTP (curl): Roboty dla małych stron
- Duże pobranie: Stajnie po uścisku dłoni TCP
-
Badanie MTU:
ping -M do -s 1472sukces,ping -M do -s 1473niepowodzenie - Monitorowanie ICMP: Brak wiadomości "Fragmentacja wymagana" (typ 3 Kod 4)
Root Cause
Tunel VPN zmniejszył MTU do 1400, ale firewall blokował wiadomości ICMP "Fragmentation Needed". Path MTU Discovery (PMTUD) nie mógł pracować, tworząc czarną dziurę MTU. Małe pakiety pasujące, duże pakiety z ustawionym bitem DF zostały po cichu upuszczone.
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
Rozmiar ma znaczenie: Jeśli małe prośby działają, ale duże transfery zawodzą, podejrzewamy problemy z MTU / fragmentacji. Użyj ping z bitem DF do przetestowania ścieżki MTU.
Badanie przypadku 4: Kwestie jakości VoIP (Właściwie: Błąd QoS)
Symptom
Telefony głosowe były głośne, przerywane. Wystąpiło tylko w godzinach pracy (9- 5pm).
Initial Assumptions (Wrong)
- Niewystarczająca szerokość pasma
- Przeładowany serwer VoIP
- Jakość połączenia ISP
Diagnostic Process
- Badanie szerokości pasma: Link tylko 40% wykorzystywane w godzinach pracy
- Kontrola QoS: Ruch głosowy oznaczony DSCP EF (46) prawidłowo
- Kontrola kolejki: Kolejka głosowa miała tylko 5% przydział przepustowości (powinien być 33%)
- Wychwytywanie pakietów: Pakiety głosowe upuszczane podczas zatorów
Root Cause
Polityka QoS istniała, ale przydział przepustowości był do tyłu: najlepszy wysiłek dostał 60%, głos dostał 5%. Podczas godzin pracy, gdy ruch danych wzrosła, pakiety głosowe zostały wycofane z powodu przepełnienia kolejki.
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
Kwestie czasowe = pojemność: Jeśli problemy pojawiają się tylko w godzinach pracy, nie jest to trudna porażka, ale problem pojemności / QoS. Sprawdź statystyki kolejki, nie tylko całkowitą przepustowość.
Odniesienie do komendy przez symptom
| Objawy | Warstwa | Polecenia do uruchomienia | Co szukać |
|---|---|---|---|
| Brak światła | Warstwa 1 | show interfaces |
Status: w dół, brak nośnika, odłączony kabel |
| Utrata pakietu | Warstwa 1 / 2 | show interfaces |
Błędy CRC, biegi, giganty, kolizje, późne kolizje |
| Nie można ping brama | Warstwa 2 | arp -a |
Brak wpisu ARP, MAC nie nauczył, STP blokowanie |
| Nie mogę dosięgnąć zdalnej podsieci | Warstwa 3 | traceroute |
Brakująca trasa, zły następny-hop, pętla routingu |
| Odmowa połączenia | Warstwa 4 | telnet host port |
Niesłuchanie usługi, blokada zapory, TCP RST |
| Powolne osiągi | Warstwa 4 + | ping (RTT) |
Wysoka latencja, limit przepustowości, retransmisje TCP, zero okien |
| Nie można rozwiązać nazwy komputera | Warstwa 7 | nslookup |
Serwer DNS nieosiągalny, zła konfiguracja DNS, NXDOMAIN |
| Krople przerywane | Layer 1/2 | ping -f (flood) |
Niedopasowanie Duplex, awaria kabla, powrót STP |
| Czasami działa, nie inne | Wiele | Extended ping |
Kwestia bilansowania obciążenia, asymetria ECMP, przepełnienie tabeli stanu |
Kiedy Escalate
Wiedzieć, kiedy eskalacja do TAC sprzedawcy lub starszych inżynierów. Eskalować, gdy:
- Wyczerpałeś wszystkie kroki w bazie wiedzy.
- Wydanie wymaga dostępu / uprawnień, których nie masz
- Problem wiąże się z błędami oprogramowania sprzedawcy lub wadą sprzętu
- Wpływ działalności gospodarczej jest krytyczny i wrażliwy na czas
- Wiele zespołów musi współpracować (aplikacja + sieć + serwer)
- Kompletny opis objawów
- Terminy rozpoczęcia emisji
- Polecenia diagnostyczne uruchamiane i ich wyjście
- Kopie zapasowe konfiguracji
- Uchwyty pakietów (w stosownych przypadkach)
- Co już próbowałeś
Budowanie osobistej bazy wiedzy
Każda sesja jest okazją do nauki. Zbuduj osobistą bazę wiedzy:
1. Utwórz dziennik rozwiązywania problemów
# 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. Zbuduj arkusz poleceń
Zorganizuj często używane polecenia według scenariusza dla szybkiego odniesienia podczas rozwiązywania problemów.
3. Dokumentacja Twojej sieci
- Schematy topologiczne (warstwa 2 i warstwa 3)
- Dokumentacja systemu adresów IP
- Przydziały VLAN
- Konfiguracje standardowe (szablony)
- Znakomite podstawowe (statystyki interfejsu przed problemami)
Często
NIE ZALEŻNIJ: Dokonaj losowych zmian bez diagnozy
Zmiana konfiguracji bez zrozumienia problemu często pogarsza sytuację lub maskuje prawdziwy problem.
Załóżmy, że sieć jest zawsze winna.
Często "problemy sieciowe" to problemy aplikacji, serwera lub klienta. Zbierz dowody, zanim zaakceptujesz winę.
PROJECT 'T: Pomiń dokumentowanie kroków
Stracisz czas na powtarzanie testów, które już zrobiłeś, albo nie będziesz w stanie wyjaśnić kolegom, czego próbowałeś.
Ignoruj problemy przerywane
Problemy okresowe są często wczesne objawy ostrzegawcze zbliżającej się awarii. Zbadaj je zanim staną się krytyczne.
DOWODNIE: Napraw objawy zamiast przyczyn
Restartowanie urządzenia może przywrócić obsługę, ale jeśli nie dowiesz się, dlaczego potrzebne jest ponowne uruchomienie, problem się powtórzy.
Podsumowanie: Lista kontrolna systematycznego rozwiązywania problemów
Przed rozpoczęciem
- Odpowiedź na pięć kluczowych pytań (Co się zmieniło? Kto ucierpiał? Stałe czy przerywane? Odtwarzalny? Co widzi druga strona?)
- Zbierz początkowe objawy i raporty użytkowników
- Sprawdź ostatnie zmiany lub konserwację
■ Podczas rozwiązywania problemów
- Przer. metodycznie przez warstwy OSI (do góry lub do góry)
- Zmień jedną zmienną w czasie badania
- Dokumentuj każdy test i jego wynik
- Użyj przechwytywania pakietów, aby zobaczyć rzeczywiste zachowanie ruchu
- Porównaj ze znanymi poziomami bazowymi
ŘPo rozwiązaniu
- Weryfikacja poprawki faktycznie rozwiązała problem
- Podstawowa przyczyna i rozdzielczość dokumentu
- Aktualizuj bazę wiedzy
- Jeśli konfiguracja się zmieniła, uaktualnij dokumentację
- Zastanówcie się: Czy monitoring mógł złapać to wcześniej?
Wniosek
Rozwiązywanie problemów sieciowych to nauka i sztuka. Nauka stosuje systematyczną metodologię, używając prawidłowo narzędzi diagnostycznych i protokołów zrozumienia. Sztuka jest wiedzieć, które testy najpierw na podstawie objawów, rozpoznawanie wzorców z doświadczenia, i wiedzieć, kiedy eskalacji.
Podążając za systematycznym podejściem opisanym w tym artykule - zadając właściwe pytania, pracując metodycznie za pośrednictwem modelu OSI, dokumentując swoje kroki i ucząc się z każdej kwestii - stajesz się bardziej skuteczny w rozwiązywaniu problemów i unikaniu wspólnych pułapek, które prowadzą do marnowania czasu i nieprawidłowych poprawek.
Pamiętaj: Celem nie jest tylko przywrócenie usługi, ale zrozumieć, dlaczego nie udało się, aby można było zapobiec to ponownie.
Ostatnia aktualizacja: 2 lutego 2026 r.