Ongelma:
Ratkaisu:
Kustannukset Haphazard Vianmääritys:
Verkon vianmääritys on pohjimmiltaan tieteellisen menetelmän mukaista:
Tässä artiklassa luodaan järjestelmä verkon vianmääritystä varten, joka estää yhteisiä sudenkuoppia, kuten:
Ennen kuin sukellatte tekniseen diagnostiikkaan, vastatkaa näihin viiteen kriittiseen kysymykseen.
OSI-malli tarjoaa jäsennellyt puitteet vianmääritystä varten. Työ tasosta 1 (Fysikaalinen) ylöspäin tai tasosta 7 (sovellus) alaspäin, riippuen oireista.
Milloin valmistetta käytetään:
Milloin valmistetta käytetään:
Aloita tasosta 7 (Onko SharePoint-palvelu käynnissä? DNS ratkaista korjata IP?) ja työskennellä alas vain tarvittaessa.
Käytä tätä nopeaa diagnostista puu tunnistaa, mikä kerros on epäonnistunut:
Kun sinulla on hypoteesi syy, käytä näitä eristystekniikoita vahvistaa tai hylätä se:
Kaapataan liikenne lähtö-, väli- ja määräpaikkaan, jotta voidaan tunnistaa, missä paketteja pudotetaan tai muutetaan:
# 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
Poistetaan ulkoiset muuttujat testaamalla liitettävyyttä yhdellä laitteella:
# 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
Vertaa asetuksia ja käyttäytymistä työjärjestelmään:
# 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")
Oikea dokumentaatio estää pyöreän vianetsinnän, jossa yrität samaa asiaa useita kertoja huomaamatta sitä.
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
Database-sovelluksen vasteajat ovat heikentyneet <100 m:stä 5+ sekunnien. Sovellusryhmä syytti verkkoviivettä.
Tietokannan palvelimen käyttöjärjestelmän puskurit olivat liian pieniä korkean kaistanleveyden × viive tuotteen. TCP-ikkuna täyttyi, joten lähettäjä odotti.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Älä oleta:
Palvelimen yhteys putoaisi satunnaisesti, erityisesti kuormitettuna. Joskus toimi hyvin, joskus täysin reagoimatta.
Automaattinen neuvottelu epäonnistui. Palvelin neuvotteli täysduplex, vaihto putosi takaisin puoli-duplex. Yhteentörmäykset tapahtuivat vain kuormitettuna, kun molemmat puolet yrittivät lähettää samanaikaisesti.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Tarkista molemmat päät:
Käyttäjät voisivat selata joitakin sivustoja (Google, Yahoo) mutta ei muita (pankkisivusto, yritysportaali). Pienet HTTP-pyynnöt toimivat, suuret sivut ajoitettu.
ping -M do -s 1472ping -M do -s 1473VPN tunneli laski MTU 1400, mutta palomuuri oli estää ICMP "Fragmentation Need" -viestit. Polku MTU Discovery (PMTUD) ei voinut toimia, luoda MTU musta aukko. Pienet paketit sopivat, suuret DF-bittiset paketit putosivat hiljaa.
! 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
Kokoa koskevat asiat:
Puheluissa oli pätkiä, ajoittaisia keskeyttäjiä. Tapahtui vain työaikana (9.00-17.00).
QoS-politiikka oli olemassa, mutta kaistanleveyden jako oli takaperin: paras tavoite sai 60%, ääni sai 5%. Bisnesaikana, jolloin dataliikenne lisääntyi, puhepaketit putosivat jonon ylivuodon vuoksi.
! 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
Aikaperusteiset kysymykset = kapasiteetti:
| Oireet | Taso | Suoritettavat komennot | Mitä etsit? |
|---|---|---|---|
| Ei linkkivaloa | Taso 1 | show interfaces |
Tila: alas, ei kantolaitetta, kaapeli irrotettu |
| Pakkauksen menetys | Kerros 1/2 | show interfaces |
CRC-virheet, räntit, jättiläiset, törmäykset, myöhäiset törmäykset |
| En voi ping-porttia | Taso 2 | arp -a |
Ei ARP merkintä, MAC ei oppinut, STP esto |
| -Ei onnistu. | Taso 3 | traceroute |
Puuttuu reitti, väärä seuraava hop, reitityssilmukka |
| Yhteys evätty | Taso 4 | telnet host port |
Palvelu, palomuuri, TCP RST |
| Hidas suorituskyky | Taso 4+ | ping (RTT) |
Suuri latenssi, kaistanleveys, TCP-lähetykset, nollaikkunat |
| Ei voi ratkaista isäntänimeä | Taso 7 | nslookup |
DNS-palvelin tavoittamaton, väärä DNS config, NXDOMAIN |
| Jaksottaiset pudotukset | Layer 1/2 | ping -f (flood) |
Duplex-ero, viallinen kaapeli, STP-konvergenssi |
| Toimii joskus, ei muut | Useita | Extended ping |
Kuormituksen tasapainottaminen, ECMP-epäsymmetria, tilataulukon ylivuoto |
Tiedä milloin edetä myyjä TAC tai vanhempi insinöörejä. Escalate, kun:
Jokainen vianmääritys on oppimismahdollisuus. Luo henkilökohtainen tietopohja:
# 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
Järjestä usein käytetyt komennot skenaarion mukaan nopeaa viittausta vianetsinnän aikana.
Konfiguraatioiden muuttaminen ymmärtämättä ongelmaa usein pahentaa asioita tai peittää todellisen ongelman.
Usein "verkko-ongelmat" ovat sovellus-, palvelin- tai asiakaspuolen ongelmia. Kerää todisteita ennen kuin otat syyt niskoillesi.
Tuhlaat aikaa toistellessasi jo tekemiäsi kokeita tai et pysty selittämään kollegoillesi, mitä olet yrittänyt.
Väliaikaiset ongelmat ovat usein varhaisen varoituksen merkkejä lähestyvästä epäonnistumisesta. Tutkikaa heidät ennen kuin heistä tulee kriittisiä.
Laitteen uudelleenkäynnistys saattaa palauttaa palvelun, mutta jos et saa selville, miksi se tarvitsi uudelleenkäynnistystä, ongelma toistuu.
Verkon vianmääritys on sekä tiedettä että taidetta. Tiede noudattaa systemaattista metodologiaa, käyttää diagnostisia työkaluja oikein ja ymmärtää protokollia. Taide on tietää, mitkä testit tehdään ensin oireiden perusteella, tunnistaa kuvioita kokemuksesta, ja tietää, milloin edetä.
Seuraamalla systemaattista lähestymistapaa, joka on esitetty tässä artikkelissa.Pyydämällä oikeita kysymyksiä, toimimalla järjestelmällisesti OSI-mallin kautta, dokumentoimalla askeleitasi ja oppimalla jokaisesta ongelmasta.
Muista:
Viimeksi päivitetty: 2 helmikuu 2026