.. pealkiri: Võrgu tõrkeotsingu metoodika – süstemaatiline lähenemine
.. nälkjas: võrgu tõrkeotsing-metoodika
.. kuupäev: 2026-02-02 18:00:00 UTC
.. sildid: võrgundus, tõrkeotsing, metoodika, diagnostika
.. kategooria: artiklid
.. link:
.. kirjeldus: süstemaatiline teaduslik lähenemine võrgu tõrkeotsingule, mis hoiab ära ajaraiskamise ja valede paranduste tegemise
.. tüüp: tekst
<style>
.article-container {
    max-width: 900px;
    margin: 0 auto;
    padding: 20px;
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    line-height: 1.8;
    color: #333;
}

h1 {
    color: #2c3e50;
    border-bottom: 3px solid #3498db;
    padding-bottom: 15px;
    margin-bottom: 30px;
}

h2 {
    color: #2c3e50;
    margin-top: 40px;
    margin-bottom: 20px;
    border-left: 5px solid #3498db;
    padding-left: 15px;
}

h3 {
    color: #34495e;
    margin-top: 30px;
    margin-bottom: 15px;
}

.intro-box {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    padding: 30px;
    border-radius: 12px;
    margin-bottom: 30px;
}

.intro-box h2 {
    color: white;
    border: none;
    margin-top: 0;
}

.warning-box {
    background: #fff3cd;
    border-left: 5px solid #ffc107;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.info-box {
    background: #d1ecf1;
    border-left: 5px solid #17a2b8;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.success-box {
    background: #d4edda;
    border-left: 5px solid #28a745;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.danger-box {
    background: #f8d7da;
    border-left: 5px solid #dc3545;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.flowchart {
    background: #f8f9fa;
    padding: 30px;
    border-radius: 12px;
    margin: 30px 0;
    border: 2px solid #dee2e6;
}

.flowchart-step {
    background: white;
    border: 2px solid #3498db;
    padding: 20px;
    margin: 15px 0;
    border-radius: 8px;
    position: relative;
}

.flowchart-step.decision {
    border-color: #e74c3c;
    background: #fee;
}

.flowchart-step.success {
    border-color: #27ae60;
    background: #efe;
}

.flowchart-arrow {
    text-align: center;
    font-size: 24px;
    color: #3498db;
    margin: 10px 0;
}

.command-box {
    background: #2d2d2d;
    color: #f8f8f2;
    padding: 20px;
    border-radius: 8px;
    font-family: 'Courier New', monospace;
    overflow-x: auto;
    margin: 20px 0;
}

.command-box code {
    color: #f8f8f2;
}

table {
    width: 100%;
    border-collapse: collapse;
    margin: 25px 0;
}

th, td {
    padding: 12px;
    text-align: left;
    border: 1px solid #dee2e6;
}

th {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    font-weight: 600;
}

tr:nth-child(even) {
    background: #f8f9fa;
}

.case-study {
    background: #f8f9fa;
    border-radius: 12px;
    padding: 25px;
    margin: 30px 0;
    border-left: 5px solid #3498db;
}

.case-study h3 {
    color: #3498db;
    margin-top: 0;
}

.checklist {
    list-style: none;
    padding: 0;
}

.checklist li {
    padding: 10px 10px 10px 35px;
    margin: 8px 0;
    background: #f8f9fa;
    border-radius: 6px;
    position: relative;
}

.checklist li:before {
    content: '✓';
    position: absolute;
    left: 10px;
    color: #28a745;
    font-weight: bold;
    font-size: 18px;
}

.tip-box {
    background: #e7f3ff;
    border-left: 5px solid #2196F3;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.tip-box strong {
    color: #2196F3;
}
</style>
<div class="article-container">
<h1>Võrgu tõrkeotsingu metoodika: süstemaatiline lähenemine</h1>
<div class="intro-box">
<h2>Miks metoodika on oluline</h2>
<p><strong>Probleem:</strong>Andmebaasirakendus on "aeglane". Võrgumeeskond süüdistab serverimeeskonda. Serverimeeskond süüdistab võrku. Samal ajal on kasutajad pettunud ja tunde raisatakse ringikujulisele silumisele.</p>
<p><strong>Lahendus:</strong>Süstemaatiline, teaduslik lähenemisviis tõrkeotsingule, mis kasutab algpõhjuste tuvastamiseks tõendeid, mitte eeldusi.</p>
<p><strong>Juhusliku tõrkeotsingu maksumus:</strong>Raisatud aeg, valed parandused, mis varjavad tegelikke probleeme, meeskondade vahel näpuga näitamine ja halvenenud kasutajakogemus.</p>
</div>
<h2>Sissejuhatus: võrgustike loomisel rakendatav teaduslik meetod</h2>
<p>Võrgu tõrkeotsing on põhimõtteliselt teadusliku meetodi harjutus:</p>
<ol>
<li><strong>Jälgige</strong>sümptomid ja koguda andmeid</li>
<li><strong>Moodustage hüpotees</strong>algpõhjuse kohta</li>
<li><strong>Testige hüpoteesi</strong>diagnostikavahenditega</li>
<li><strong>Analüüsige tulemusi</strong>ja hüpoteesi kinnitada või ümber lükata</li>
<li><strong>Rakendage parandus</strong>põhineb kinnitatud algpõhjusel</li>
<li><strong>Kinnitage</strong>probleem on lahendatud</li>
</ol>
<p>See artikkel pakub võrgu tõrkeotsingu struktureeritud raamistikku, mis hoiab ära levinud lõkse, nagu:</p>
<ul>
<li>Kinnituse eelarvamus (ainult teie esialgset oletust toetavate tõendite otsimine)</li>
<li>Juhuslikud muutused ilma diagnoosita ("pihusta ja palveta" lähenemisviis)</li>
<li>Sümptomite parandamine algpõhjuste asemel</li>
<li>Ringikujuline silumine ilma proovitut dokumenteerimata</li>
</ul>
<h2>Viis võtmeküsimust</h2>
<p>Enne tehnilisse diagnostikasse sukeldumist vastake oma uurimisulatuse kitsendamiseks viiele kriitilisele küsimusele:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>1. küsimus: mis on hiljuti muutunud?</strong>
<p>Konfiguratsiooni muutused? Uus riistvara? Tarkvarauuendused? Topoloogia muudatused?</p>
<ul>
<li>Kontrollige muudatuste haldamise logisid</li>
<li>Vaadake üle hiljutised kohustused konfiguratsioonihaldussüsteemides</li>
<li>Küsige: "Kas see eile töötas?"</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>2. küsimus: keda see mõjutab?</strong>
<p>Üks kasutaja? Üks hoone? Kõik? Ainult konkreetne rakendus?</p>
<ul>
<li><strong>Üks seade:</strong>Tõenäoliselt kohalik probleem (NIC, kaabel, konfiguratsioon)</li>
<li><strong>Üks alamvõrk:</strong>Lüüsi, DHCP või lüliti probleem</li>
<li><strong>Kõik:</strong>Põhiinfrastruktuur, Interneti-teenuse pakkuja või laialt levinud probleem</li>
<li><strong>Konkreetne rakendus:</strong>Rakendusserver, tulemüürireegel või DNS</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>3. küsimus: kas see on pidev või vahelduv?</strong>
<p>Juhtub kogu aeg? Kas ainult teatud kellaaegadel? Juhuslikud juhtumid?</p>
<ul>
<li><strong>Püsiv:</strong>Raske rike (kaabli läbilõikamine, vale konfiguratsioon, katkendlik teenindus)</li>
<li><strong>Ajapõhine:</strong>Ummikud tööajal, planeeritud protsessid</li>
<li><strong>Katkendlik/juhuslik:</strong>Dupleksne mittevastavus, rike riistvara, katkendlik link</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>4. küsimus: kas saate seda reprodutseerida?</strong>
<p>Kas saate probleemi nõudmisel käivitada?</p>
<ul>
<li><strong>Jah:</strong>Palju lihtsam diagnoosida (saab testida hüpoteese)</li>
<li><strong>Ei:</strong>Seadistage jälgimine/logimine ja oodake kordumist</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>5. küsimus: mida näeb teine ​​pool?</strong>
<p>Kontrollige ühenduse mõlemat otsa</p>
<ul>
<li>Kliendi vaatenurk vs serveri vaatenurk</li>
<li>Paketthõive lähtekohas vs. sihtkohas</li>
<li>Asümmeetriline marsruutimine? Kas saatmise ja vastuvõtmise erinevad teed?</li>
</ul>
</div>
</div>
<h2>OSI mudelipõhine diagnostikameetod</h2>
<p>OSI mudel pakub tõrkeotsinguks struktureeritud raamistikku. Sõltuvalt sümptomitest töötage 1. kihist (füüsiline) ülespoole või 7. kihist (rakendus) allapoole.</p>
<h3>Alt-üles lähenemine (1. kiht → 7. kiht)</h3>
<p><strong>Millal kasutada:</strong>Ühenduvuse täielik kaotus, lingivalgustuse puudumine või füüsilise kihi sümptomid</p>
<div class="flowchart">
<div class="flowchart-step">
<strong>1. kiht: füüsiline</strong>
<ul>
<li>Kontrollige: kaabel on ühendatud? Lingi tuled põlevad? Kiud puhas?</li>
<li>Käsud:<code>show interfaces</code>, <code>ethtool eth0</code></li>
<li>Otsige: CRC vead, kokkupõrked, hilised kokkupõrked, jooksud, hiiglased</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>2. kiht: andmeside</strong>
<ul>
<li>Kontrollige: kas VLAN on õige? Port on lubatud? STP blokeerimine?</li>
<li>Käsud:<code>show mac address-table</code>, <code>show spanning-tree</code></li>
<li>Otsige: MAC-i klappimine, STP topoloogia muutused, VLAN-i mittevastavused</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>3. kiht: võrk</strong>
<ul>
<li>Kontrollige: kas vaikelüüsi saab pingida? Kas marsruutimistabel on õige?</li>
<li>Käsud:<code>ping</code>, <code>traceroute</code>, <code>show ip route</code></li>
<li>Otsige: puuduvad marsruudid, vale järgmine hüpe, marsruutimise silmused</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>4. kiht: transport</strong>
<ul>
<li>Kontrollige: kas saab luua TCP-ühenduse? Kas tulemüür blokeerib porti?</li>
<li>Käsud:<code>telnet host port</code>, <code>netstat -an</code>, pakettide püüdmine</li>
<li>Otsige: TCP kordusedastused, null aknad, RST paketid</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Kiht 5-7: seanss/esitlus/rakendus</strong>
<ul>
<li>Kontrollige: DNS-i lahendamine? Kas rakendus vastab? Autentimine töötab?</li>
<li>Käsud:<code>nslookup</code>, <code>dig</code>, <code>curl -v</code></li>
<li>Otsige: DNS-i tõrkeid, rakenduse vigu, ajalõpu probleeme</li>
</ul>
</div>
</div>
<h3>Ülalt-alla lähenemine (7. kiht → 1. kiht)</h3>
<p><strong>Millal kasutada:</strong>Rakenduspõhised probleemid, kui on olemas põhiline ühenduvus</p>
<div class="info-box">
<strong>Näide:</strong>"Ma saan Internetti sirvida, kuid ma ei pääse ettevõtte SharePointi saidile."<p>Alustage 7. kihist (kas SharePointi teenus töötab? DNS lahendab õige IP-aadressi?) ja vähendage ainult vajaduse korral.</p>
</div>
<h2>Otsustuspuu: kas see on kiht 1, 2 või 3?</h2>
<p>Kasutage seda kiiret diagnostikapuud, et tuvastada, milline kiht ebaõnnestub:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>Kas saate pingida localhosti (127.0.0.1)?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: operatsioonisüsteemi/tarkvara probleem</strong>
<p>TCP/IP pinu ei tööta. Kontrollige OS-i teenuseid, installige võrgudraiverid uuesti.</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step decision">
<strong>Kas saate oma IP-aadressi pingida?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: kiht 1/2 – kohaliku võrgu liides</strong>
<p>NIC on keelatud, vale draiver, kaabel on lahti ühendatud. Kontrollige:<code>ip link show</code>või Seadmehaldur</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step decision">
<strong>Kas saate vaikelüüsi pingida?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: kiht 1/2 – kohalik võrk</strong>
<p>Kontrollige: füüsiline kaabel, lüliti pordi olek, VLAN-i määramine, ARP-tabel</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step decision">
<strong>Kas saate kaughosti IP-aadressi järgi pingida?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: kiht 3 – marsruutimine</strong>
<p>Kontrollige: marsruutimistabel, tulemüürireeglid, ACL-id. Kasutage<code>traceroute</code>et leida, kus paketid peatuvad</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step decision">
<strong>Kas saate DNS-i (nslookupi hostinimi) lahendada?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: DNS-i konfiguratsioon</strong>
<p>Kontrollige: DNS-serveri sätteid, DNS-serveri saadavust, tulemüüri blokeerivat porti 53</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step decision">
<strong>Kas saate jõuda rakenduse porti (telneti hostiporti)?</strong>
</div>
<div class="flowchart-arrow">↓ EI</div>
<div class="flowchart-step danger">
<strong>Probleem: tulemüür / pordi blokeerimine</strong>
<p>Kontrollige: tulemüüri reeglid, turvarühmad, teenuse kuulamine pordis</p>
</div>
<div class="flowchart-arrow">↓ JAH</div>
<div class="flowchart-step success">
<strong>Võrk on korras – rakenduskihi probleem</strong>
<p>Probleem on rakenduse enda, autentimise või rakenduse konfiguratsiooniga</p>
</div>
</div>
<h2>Isolatsioonitehnikad</h2>
<p>Kui teil on algpõhjuse kohta hüpotees, kasutage selle kinnitamiseks või ümberlükkamiseks järgmisi isoleerimismeetodeid.</p>
<h3>1. Asendage komponendid süstemaatiliselt</h3>
<div class="tip-box">
<strong>Näpunäide:</strong>Muutke korraga ÜHE muutujat. Kui vahetate nii kaabli kui ka lüliti pordi, ei saa te teada, kumb selle parandas.</div>
<ul class="checklist">
<li>Vahetage patch-kaabel tuntud hea kaabli vastu</li>
<li>Testige erineva lüliti pordiga</li>
<li>Proovige teist NIC-i (või USB-võrguadapterit)</li>
<li>Test erinevatest kliendiseadmetest</li>
<li>Liikuge teise VLAN-i/alamvõrku</li>
</ul>
<h3>2. Pakettide hõivamine mitmes punktis</h3>
<p>Jäädvustage liiklust allikas, vahepunktides ja sihtkohas, et teha kindlaks, kus paketid kukutatakse või muudetakse:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>3. Loopback testimine</h3>
<p>Kõrvaldage välised muutujad, testides ühenduvust ühes seadmes:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>4. Teadaolevate heade lähtetasemete võrdlused</h3>
<p>Võrrelge konfiguratsiooni ja käitumist töötava süsteemiga:</p>
<div class="command-box">
<code># Compare interface settings
diff &lt;(ssh working-switch "show run int gi1/0/1") \
     &lt;(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff &lt;(ssh router1 "show ip route") \
     &lt;(ssh router2 "show ip route")
</code>
</div>
<h2>Dokumentatsioon tõrkeotsingu ajal</h2>
<p>Korrektne dokumentatsioon hoiab ära ümmarguse silumise, kui proovite sama asja mitu korda aru saamata.</p>
<h3>Veaotsingu mall</h3>
<div class="command-box">
<code><strong>Probleemi ID:</strong> TICKET-12345
<strong>Kuupäev/kellaaeg:</strong> 2026-02-02 14:30 UTC
<strong>Teataja:</strong> Jane Smith (jane.smith@company.com)
<strong>Mõjutatud kasutajad:</strong> ~50 users in Building A, 3rd floor
<strong>Sümptom:</strong> Cannot access file server \\fileserver01

<strong>Esialgsed tähelepanekud:</strong>
- 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

<strong>Läbiviidud testid:</strong>
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

<strong>Algpõhjus:</strong>
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

<strong>Resolutsioon:</strong>
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

<strong>Kinnitamine:</strong>
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

<strong>Aeg lahenduseni:</strong> 25 minutes
</code>
</div>
<div class="warning-box">
<strong>Miks on dokumentatsioon oluline:</strong>Ilma selle kirjeta võib järgmine kord, kui keegi näeb sellel lülitil CRC-vigu, raisata aega kaablite vahetamisele ja portide testimisele, selle asemel et kohe kiu puhtust kontrollida.</div>
<h2>Reaalse maailma juhtumiuuringud</h2>
<h3>Juhtumiuuring 1: "Võrk on aeglane" (tegelikult: TCP-akna ammendumine)</h3>
<div class="case-study">
<h3>Sümptom</h3>
<p>Andmebaasirakenduse reaktsiooniajad vähenesid &lt;100 ms-lt 5+ sekundile. Rakenduse meeskond süüdistas "võrgu latentsust".</p>
<h3>Esialgsed oletused (valed)</h3>
<ul>
<li>Võrgu ülekoormus</li>
<li>WAN-link on küllastunud</li>
<li>Tulemüüri kitsaskoht</li>
</ul>
<h3>Diagnostiline protsess</h3>
<ol>
<li><strong>Ping test:</strong>RTT = 2 ms (suurepärane, välistab kihi 3 latentsuse)</li>
<li><strong>Ribalaiuse test (iperf):</strong>950 Mbps 1 Gbps lingil (ummikuteta)</li>
<li><strong>Paketi püüdmine:</strong>Andmebaasiserverist ilmunud TCP Zero Window paketid</li>
<li><strong>Serveri kontroll:</strong>Andmebaasiserveri vastuvõtupuhvrid = 64 KB (väike!)</li>
</ol>
<h3>Algpõhjus</h3>
<p>Andmebaasiserveri OS-i puhvrid olid suure ribalaiusega × viivitusega toote jaoks liiga väikesed. TCP aken täitub, sundides saatjat ootama.</p>
<h3>Resolutsioon</h3>
<div class="command-box">
<code># Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
</code>
</div>
<h3>Õppetund</h3>
<p><strong>Ära eelda:</strong>"Aeglane" ei tähenda alati "võrgu latentsust". Enne kiirete järelduste tegemist koguge alati tõendeid (ping latentsusaja jaoks, pakettide püüdmine käitumise kohta).</p>
</div>
<h3>Juhtumiuuring 2: katkendlik ühenduvus (tegelikult: dupleksi mittevastavus)</h3>
<div class="case-study">
<h3>Sümptom</h3>
<p>Serveriühendus katkeb juhuslikult, eriti koormuse korral. Mõnikord töötas hästi, mõnikord ei reageerinud.</p>
<h3>Esialgsed oletused (valed)</h3>
<ul>
<li>Ebaõnnestunud NIC</li>
<li>Halb kaabel</li>
<li>Lüliti riistvara probleem</li>
</ul>
<h3>Diagnostiline protsess</h3>
<ol>
<li><strong>Liidese kontroll:</strong>Serveri võrgukaart = 1000 / täis, lüliti port = 1000 / pool (mittevastavus!)</li>
<li><strong>Vea loendurid:</strong>Suur kokkupõrgete arv lüliti pordis</li>
<li><strong>Hilised kokkupõrked:</strong>Dupleksi mittevastavuse indikaator</li>
</ol>
<h3>Algpõhjus</h3>
<p>Automaatne läbirääkimine ebaõnnestus. Server sõlmis täisdupleksrežiimi, lüliti lülitus tagasi pooldupleksrežiimile. Kokkupõrked toimusid ainult koormuse all, kui mõlemad pooled üritasid edastada samaaegselt.</p>
<h3>Resolutsioon</h3>
<div class="command-box">
<code>! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full
</code>
</div>
<h3>Õppetund</h3>
<p><strong>Kontrollige mõlemat otsa:</strong>Liidese olek näitab kokkulepitud sätteid. Mittevastavus tähendab, et automaatne läbirääkimine ebaõnnestus. Serverite jaoks alati kõvakoodi kiirus/dupleks.</p>
</div>
<h3>Juhtumiuuring 3: "Ei pääse teatud veebisaitidele" (tegelikult: MTU/PMTUD must auk)</h3>
<div class="case-study">
<h3>Sümptom</h3>
<p>Kasutajad said sirvida mõnda veebisaiti (Google, Yahoo), kuid mitte teisi (panga veebisait, ettevõtte portaal). Väikesed HTTP-päringud töötasid, suured lehed aegusid.</p>
<h3>Esialgsed oletused (valed)</h3>
<ul>
<li>DNS-i probleem</li>
<li>Tulemüür blokeerib teatud saidid</li>
<li>ISP marsruutimise probleem</li>
</ul>
<h3>Diagnostiline protsess</h3>
<ol>
<li><strong>DNS-i eraldusvõime:</strong>Töötab hästi kõikide saitide puhul</li>
<li><strong>Ping test:</strong>Saab pingida "kättesaamatutele" saitidele</li>
<li><strong>Väike HTTP-päring (kõver):</strong>Töötab väikeste lehtede jaoks</li>
<li><strong>Suur allalaadimine:</strong>Seiskub pärast TCP käepigistust</li>
<li><strong>MTU test:</strong> <code>ping -M do -s 1472</code>õnnestub,<code>ping -M do -s 1473</code>ebaõnnestub</li>
<li><strong>ICMP jälgimine:</strong>Ühtegi teadet "Killustada on vaja" (tüüp 3, kood 4) ei saadud</li>
</ol>
<h3>Algpõhjus</h3>
<p>VPN-tunnel vähendas MTU-d 1400-ni, kuid tulemüür blokeeris ICMP-teateid "Vajalik killustatus". Path MTU Discovery (PMTUD) ei saanud töötada, luues MTU musta augu. Väikesed paketid sobisid, suured paketid DF-bitikomplektiga langesid vaikselt maha.</p>
<h3>Resolutsioon</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Õppetund</h3>
<p><strong>Suurus on oluline:</strong>Kui väikesed päringud töötavad, kuid suured ülekanded ebaõnnestuvad, kahtlustage MTU/killustumise probleeme. Kasutage tee MTU testimiseks pingi DF-bitiga.</p>
</div>
<h3>Juhtumiuuring 4: VoIP-kvaliteediprobleemid (tegelikult: QoS-i vale konfiguratsioon)</h3>
<div class="case-study">
<h3>Sümptom</h3>
<p>Häälkõnede heli oli katkendlik, katkestused katkesid. Toimus ainult tööajal (9.00-17.00).</p>
<h3>Esialgsed oletused (valed)</h3>
<ul>
<li>Ebapiisav ribalaius</li>
<li>VoIP-server on ülekoormatud</li>
<li>ISP ühenduse kvaliteet</li>
</ul>
<h3>Diagnostiline protsess</h3>
<ol>
<li><strong>Ribalaiuse test:</strong>Kiirel tunnil kasutatakse linki vaid 40%.</li>
<li><strong>QoS-i kontroll:</strong>Kõneliiklus on õigesti märgistatud DSCP EF-ga (46).</li>
<li><strong>Järjekorra kontroll:</strong>Kõnejärjekorrale oli eraldatud ainult 5% ribalaiust (peaks olema 33%)</li>
<li><strong>Paketi püüdmine:</strong>Häälepaketid langevad ummikute ajal</li>
</ol>
<h3>Algpõhjus</h3>
<p>QoS-poliitika oli olemas, kuid ribalaiuse jaotus oli tagurpidi: parim pingutus sai 60%, hääl 5%. Tööajal, mil andmeliiklus suurenes, jäeti kõnepaketid järjekorra ületäitumise tõttu välja.</p>
<h3>Resolutsioon</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Õppetund</h3>
<p><strong>Ajapõhised probleemid = võimsus:</strong>Kui probleemid ilmnevad ainult kiiretel tundidel, pole see raske rike, vaid võimsuse/QoS-i probleem. Kontrollige järjekorra statistikat, mitte ainult kogu ribalaiust.</p>
</div>
<h2>Käskude viide sümptomite järgi</h2>
<table>
<thead>
<tr>
<th>Sümptom</th>
<th>Kiht</th>
<th>Käsud jooksma</th>
<th>Mida otsida</th>
</tr>
</thead>
<tbody>
<tr>
<td>Lingi tuli puudub</td>
<td>1. kiht</td>
<td><code>show interfaces<br/>ethtool eth0</code></td>
<td>Olek: maas, kandja puudub, kaabel on lahti ühendatud</td>
</tr>
<tr>
<td>Paketi kadu</td>
<td>Kiht 1/2</td>
<td><code>show interfaces<br/>show interfaces counters errors</code></td>
<td>CRC vead, jooksud, hiiglased, kokkupõrked, hilised kokkupõrked</td>
</tr>
<tr>
<td>Lüüsi ei saa pingida</td>
<td>2. kiht</td>
<td><code>arp -a<br/>show mac address-table<br/>show spanning-tree</code></td>
<td>ARP-kirje puudub, MAC-i pole õpitud, STP blokeerimine</td>
</tr>
<tr>
<td>Kaug-alamvõrku ei saa ühendust</td>
<td>3. kiht</td>
<td><code>traceroute<br/>show ip route<br/>show ip route summary</code></td>
<td>Puuduv marsruut, vale järgmine hüpe, marsruutimissilmus</td>
</tr>
<tr>
<td>Ühendamisest keelduti</td>
<td>4. kiht</td>
<td><code>telnet host port<br/>netstat -an<br/>tcpdump</code></td>
<td>Teenus ei kuula, tulemüüri blokeerimine, TCP RST</td>
</tr>
<tr>
<td>Aeglane jõudlus</td>
<td>Kiht 4+</td>
<td><code>ping (RTT)<br/>iperf3<br/>tcpdump<br/>show interfaces</code></td>
<td>Kõrge latentsusaeg, ribalaiuse piirang, TCP kordusedastused, null akent</td>
</tr>
<tr>
<td>Hostinime ei saa lahendada</td>
<td>7. kiht</td>
<td><code>nslookup<br/>dig<br/>cat /etc/resolv.conf</code></td>
<td>DNS-server on kättesaamatu, vale DNS-i konfiguratsioon, NXDOMAIN</td>
</tr>
<tr>
<td>Vahelduvad tilgad</td>
<td>Kiht 1/2</td>
<td><code>ping -f (flood)<br/>show logging<br/>show interfaces</code></td>
<td>Dupleksi mittesobivus, kaabli rike, STP taasühinemine</td>
</tr>
<tr>
<td>Mõnikord töötab, teised mitte</td>
<td>Mitu</td>
<td><code>Extended ping<br/>Packet capture<br/>Interface statistics</code></td>
<td>Koormuse tasakaalustamise probleem, ECMP asümmeetria, olekutabeli ületäitumine</td>
</tr>
</tbody>
</table>
<h2>Millal eskaleerida</h2>
<p>Tea, millal pöörduda müüja TAC-i või vaneminseneride poole. Eskaleerida, kui:</p>
<ul class="checklist">
<li>Olete ammendanud kõik oma teadmistebaasi veaotsingu sammud</li>
<li>Probleem nõuab juurdepääsu/õigusi, mida teil pole</li>
<li>Probleem hõlmab müüja tarkvaraviga või riistvaraviga</li>
<li>Mõju äritegevusele on kriitiline ja ajatundlik</li>
<li>Koostööd peavad tegema mitu meeskonda (rakendus + võrk + server)</li>
</ul>
<div class="tip-box">
<strong>Enne eskaleerimist:</strong>Dokumenteerige kõik, mida olete proovinud. TAC-i insenerid vajavad seda teavet, et vältida teie sammude kordamist. Kaasa:<ul>
<li>Sümptomite täielik kirjeldus</li>
<li>Probleemi alguse ajakava</li>
<li>Käituvad diagnostikakäsud ja nende väljund</li>
<li>Konfiguratsiooni varukoopiad</li>
<li>Paketthõive (kui see on asjakohane)</li>
<li>Mida olete juba proovinud</li>
</ul>
</div>
<h2>Isikliku teadmistebaasi loomine</h2>
<p>Iga tõrkeotsingu seanss on õppimisvõimalus. Looge isiklik teadmistebaas:</p>
<h3>1. Looge veaotsingu päevik</h3>
<div class="command-box">
<code># 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
</code>
</div>
<h3>2. Koostage käskude petuleht</h3>
<p>Korraldage sageli kasutatavad käsud stsenaariumide järgi, et saada tõrkeotsingu ajal kiiret teavet.</p>
<h3>3. Dokumenteerige oma võrk</h3>
<ul>
<li>Topoloogia diagrammid (kiht 2 ja kiht 3)</li>
<li>IP-aadressi skeemi dokumentatsioon</li>
<li>VLAN-i ülesanded</li>
<li>Standardkonfiguratsioonid (mallid)</li>
<li>Teadaolevad head lähtejooned (liidese statistika enne probleeme)</li>
</ul>
<h2>Levinud antimustrid, mida vältida</h2>
<div class="danger-box">
<h3>❌ ÄRGE: tehke juhuslikke muudatusi ilma diagnoosita</h3>
<p>Konfiguratsioonide muutmine probleemi mõistmata muudab asjad sageli hullemaks või varjab tegelikku probleemi.</p>
</div>
<div class="danger-box">
<h3>❌ ÄRGE: eeldage, et võrk on alati viga</h3>
<p>Sageli on "võrguprobleemid" rakenduse, serveri või kliendipoolsed probleemid. Enne süü omaksvõtmist koguge tõendeid.</p>
</div>
<div class="danger-box">
<h3>❌ ÄRGE: jätke veaotsingu toimingute dokumenteerimine vahele</h3>
<p>Raiskate aega juba tehtud testide kordamisele või ei suuda kolleegidele selgitada, mida olete proovinud.</p>
</div>
<div class="danger-box">
<h3>❌ ÄRGE: ignoreerige vahelduvaid probleeme</h3>
<p>Vahelduvad probleemid on sageli varajased hoiatusmärgid eelseisvast ebaõnnestumisest. Uurige neid enne, kui need muutuvad kriitiliseks.</p>
</div>
<div class="danger-box">
<h3>❌ ÄRGE: parandage algpõhjuste asemel sümptomeid</h3>
<p>Seadme taaskäivitamine võib teenuse taastada, kuid kui te ei saa teada, MIKS see taaskäivitamist vajas, kordub probleem.</p>
</div>
<h2>Kokkuvõte: süstemaatilise tõrkeotsingu kontrollnimekiri</h2>
<div class="success-box">
<h3>✓ Enne alustamist</h3>
<ul class="checklist">
<li>Vastake viiele põhiküsimusele (Mis muutus? Keda see mõjutab? Pidevalt või vahelduvalt? Reprodutseeritav? Mida näeb teine ​​pool?)</li>
<li>Koguge kokku esialgsed sümptomid ja kasutajaaruanded</li>
<li>Kontrollige hiljutisi muudatusi või hooldust</li>
</ul>
<h3>✓ Tõrkeotsingu ajal</h3>
<ul class="checklist">
<li>Töötage metoodiliselt läbi OSI kihtide (alt-üles või ülalt-alla)</li>
<li>Muutke testimise ajal ÜHE muutujat korraga</li>
<li>Dokumenteerige iga test ja selle tulemus</li>
<li>Tegeliku liikluskäitumise nägemiseks kasutage pakettide jäädvustamist</li>
<li>Võrrelge teadaolevate heade lähteväärtustega</li>
</ul>
<h3>✓ Pärast lahendamist</h3>
<ul class="checklist">
<li>Veenduge, et parandus lahendas probleemi</li>
<li>Dokumenteerige algpõhjus ja lahendus</li>
<li>Värskendage oma teadmistebaasi</li>
<li>Kui konfiguratsiooni muudetakse, värskendage dokumentatsiooni</li>
<li>Mõelge: kas seire oleks võinud seda varem tabada?</li>
</ul>
</div>
<h2>Järeldus</h2>
<p>Võrgu tõrkeotsing on nii teadus kui ka kunst. Teadus järgib süstemaatilist metoodikat, kasutab diagnostikavahendeid õigesti ja mõistab protokolle. Kunst seisneb sümptomite põhjal teadmises, milliseid teste esimesena läbi viia, kogemustest tulenevate mustrite äratundmist ja teadmist, millal eskaleerida.</p>
<p>Järgides selles artiklis kirjeldatud süstemaatilist lähenemist – esitades õigeid küsimusi, töötades metoodiliselt läbi OSI mudeli, dokumenteerides oma sammud ja õppides igast probleemist – muutute tõrkeotsingul tõhusamaks ja väldite tavalisi lõkse, mis põhjustavad aja raiskamist ja valesid parandusi.</p>
<p><strong>Pidage meeles:</strong>Eesmärk ei ole lihtsalt teenuse taastamine, vaid mõista, MIKS see ebaõnnestus, et saaksite vältida selle kordumist.</p>
<hr style="margin-top: 40px;"/>
<p style="text-align: center; color: #6c757d;">
<em>Viimati värskendatud: 2. veebruar 2026 | Autor: Baud9600 tehniline meeskond</em>
</p>
</div>