Početna › Dijagnostika i rešavanje mrežnih problema › Teorija
💾

Teorija – Modul 20 – Dijagnostika i rešavanje mrežnih problema

Napomena: svaka tema u ovom dokumentu sadrži sedam elemenata: (1) jednostavno objašnjenje, (2) stručno objašnjenje, (3) primer iz svakodnevnog života, (4) primer iz poslovnog IT okruženja, (5) praktičnu vežbu ili napomenu, (6) najčešće greške, (7) pitanje za proveru znanja.

Tema 1 – Sistematska metodologija dijagnostike

1. Jednostavno objašnjenje

Umesto nasumičnog pokušaja i greške, postoje tri prepoznata pristupa rešavanju mrežnih problema — svaki koristan u drugačijoj situaciji.

2. Stručno objašnjenje

Bottom-up pristup počinje od fizičkog sloja (Tema 2) i ide naviše (Layer 1 → 2 → 3 → 4 → 7, OSI model iz Modula 2) — koristan kada je uzrok potpuno nepoznat, jer eliminiše najosnovnije, najčešće uzroke prve. Top-down pristup počinje od aplikacije (Layer 7) i ide naniže — koristan kada je poznato da „mreža uglavnom radi" (drugi servisi funkcionišu), pa se sumnja usmerava na konkretnu aplikaciju/servis prvo. Divide-and-conquer (podeli pa vladaj) počinje od srednjeg sloja (tipično Layer 3, mrežni) i, u zavisnosti od rezultata, grana se naviše ili naniže — najefikasniji kada postoji makar delimična indicija (npr. „ping radi, ali veb sajt ne") gde srednji test odmah eliminiše polovinu mogućih uzroka. Izbor pristupa zavisi od dostupnih informacija o problemu u trenutku kada dijagnostika počinje.

3. Primer iz svakodnevnog života

Bottom-up je kao provera automobila od najosnovnijeg (ima li goriva, je li akumulator povezan) naviše. Top-down je kao provera od najsloženijeg (zašto radio ne radi) naniže ka osnovnom. Divide-and-conquer je kao provera „da li uopšte pali motor" prvo — ako da, problem je negde „iznad" (u sistemima koji zavise od upaljenog motora); ako ne, problem je „ispod" (akumulator, gorivo, paljenje).

4. Primer iz poslovnog IT okruženja

Korisnik prijavljuje „ne mogu da otvorim interni portal" bez ikakvih drugih detalja — IT podrška bira divide-and-conquer: prvo ping ka portalu (Layer 3). Ako ping uspe, problem je „iznad" (DNS, HTTP, aplikacija) — nastavlja se top-down od te tačke. Ako ping ne uspe, problem je „ispod" (IP konfiguracija, fizička veza) — nastavlja se bottom-up od te tačke.

5. Praktična vežba / napomena

Za sledeći mrežni problem na koji naiđete (sopstveni ili tuđi), pre nego što bilo šta preduzmete, svesno odlučite koji od tri pristupa je najprikladniji na osnovu toga koliko informacija o problemu već imate.

6. Najčešće greške

  • Slepo praćenje uvek istog pristupa (npr. uvek bottom-up) bez obzira na kontekst — gubi vreme kada postojeće informacije već ukazuju gde početi.
  • Preskakanje koraka „jer je očigledno da to nije problem" — česti uzroci (labav kabl, isključen interfejs) su upravo česti zato što se olako preskaču kao „nemoguć" uzrok.

7. Pitanje za proveru znanja

P: Koji pristup biste izabrali kada korisnik kaže „internet radi, ali ne mogu da pristupim baš ovom jednom sajtu", i zašto? O: Top-down (ili divide-and-conquer usmeren visoko) — informacija da ostatak interneta radi već eliminiše fizički sloj, IP konfiguraciju i opštu rutu ka internetu kao uzrok, usmeravajući sumnju direktno na DNS rezoluciju tog konkretnog imena ili sam server/aplikaciju.

Tema 2 – Fizički sloj: kablovi, portovi, LED indikatori

1. Jednostavno objašnjenje

Najčešći uzrok „mreža ne radi" je iznenađujuće jednostavan — labav, oštećen ili pogrešno tipa kabl, ili port koji je isključen — i uvek treba proveriti prvi.

2. Stručno objašnjenje

Fizička dijagnostika (Modul 3) uključuje: proveru da je kabl fizički priključen na oba kraja i da nije vidljivo oštećen; proveru tipa kabla (straight-through naspram crossover, retko relevantno na modernoj Auto-MDIX opremi, ali i dalje bitno na starijoj); proveru LED indikatora na mrežnoj kartici/svič portu — Link LED (svetli/ne svetli = fizička veza postoji/ne postoji, nezavisno od bilo kakve konfiguracije) i Activity LED (treperi = saobraćaj postoji). Na Cisco opremi, show interfaces (Modul 7) prikazuje status line protocol (Layer 1) odvojeno od administrativnog stanja (up/down usled shutdown komande) — kombinacija ova dva statusa (up/up, up/down, administratively down/down) precizno govori da li je problem fizički, administrativan, ili kombinacija.

3. Primer iz svakodnevnog života

Provera fizičkog sloja je kao provera da li je uređaj uopšte upaljen u struju pre nego što posumnjate na složeniji kvar — trivijalno za proveriti, a iznenađujuće čest stvaran uzrok.

4. Primer iz poslovnog IT okruženja

Korisnik prijavljuje „nemam internet" — IT podrška prvo pita „da li Link LED na mrežnoj kartici svetli", i u značajnom procentu slučajeva odgovor je „ne" — kabl je slučajno izvučen (čišćenje, premeštanje opreme), rešavajući problem za manje od minuta bez ikakve dalje dijagnostike.

5. Praktična vežba / napomena

Na bilo kom Cisco uređaju iz prethodnih laboratorijskih vežbi, pokrenite show interfaces i identifikujte razliku između up, line protocol is up (potpuno funkcionalan), up, line protocol is down (fizička veza postoji, ali nešto na Layer 2 nije u redu, npr. duplex mismatch iz Teme 3), i administratively down, line protocol is down (neko je ručno pokrenuo shutdown).

6. Najčešće greške

  • Preskakanje fizičke provere jer „sigurno nije to" — upravo najčešći, najjednostavniji uzrok se najlakše previdi kada se pretpostavi da je problem složeniji nego što jeste.
  • Zabuna između administrativnog stanja (shutdown) i fizičkog stanja (line protocol) — različiti uzroci, različita rešenja (no shutdown naspram fizičke provere kabla).

7. Pitanje za proveru znanja

P: Šta znači kada show interfaces prikazuje administratively down, line protocol is down? O: Interfejs je ručno isključen komandom shutdown — administrativno stanje, ne fizički problem sa kablom; rešenje je no shutdown, ne provera kabla.

Tema 3 – Duplex mismatch

1. Jednostavno objašnjenje

Kada dva uređaja na krajevima istog kabla imaju različito podešen duplex (jedan full, drugi half), veza tehnički radi, ali sa mnogo grešaka i lošim performansama — podmukao problem jer se ne manifestuje kao potpun prekid.

2. Stručno objašnjenje

Duplex mismatch (Modul 3) nastaje kada jedan kraj veze koristi full-duplex (istovremeno slanje i primanje), a drugi half-duplex (naizmenično) — često usled toga da je jedna strana ručno podešena, a druga ostavljena na auto negotiation koja iz nekog razloga nije uspela. Simptomi: veza je aktivna (Link LED svetli), ali sa sporim performansama i visokim brojem grešaka vidljivim u show interfaces — konkretno, late collisions i CRC errors rastu na half-duplex strani. Rešenje: eksplicitno podesiti oba kraja na identičan duplex/brzinu (obično auto/auto na oba, ili full/full na oba — nikad mešavina).

3. Primer iz svakodnevnog života

Duplex mismatch je kao razgovor gde jedna osoba govori i sluša istovremeno (full-duplex), dok druga čeka da prva potpuno završi pre nego što progovori (half-duplex) — razgovor tehnički funkcioniše, ali sa čestim prekidima, ponavljanjima i opštim utiskom nesklada.

4. Primer iz poslovnog IT okruženja

Nakon zamene starog sviča novim, korisnici prijavljuju da je mreža „primetno sporija" iako je novi svič teoretski brži — dijagnostika pomoću show interfaces na oba kraja veze otkriva da je novi svič port ručno podešen na full duplex, dok stari uređaj na drugom kraju i dalje koristi auto, koja se pogrešno dogovorila na half — klasičan duplex mismatch nastao upravo zbog delimične, nekonzistentne ručne konfiguracije.

5. Praktična vežba / napomena

Na bilo kom Cisco svič portu iz prethodnih vežbi, pokrenite show interfaces <port> i pronađite red koji prikazuje trenutni duplex status i brojače grešaka (CRC, collisions) — u zdravoj vezi, ovi brojači treba da budu na nuli ili blizu nule.

6. Najčešće greške

  • Ručno podešavanje duplex/brzine na samo jednom kraju veze, ostavljajući drugi na auto — glavni uzrok duplex mismatch-a u praksi.
  • Ignorisanje rastućih brojača grešaka u show interfaces jer je veza „tehnički aktivna" — mismatch ne prekida vezu potpuno, samo drastično degradira performanse, pa se lako previdi ako se gleda samo status up/up.

7. Pitanje za proveru znanja

P: Zašto duplex mismatch ne prekida vezu potpuno, ali drastično utiče na performanse? O: Veza na Layer 1 (fizička) i dalje postoji i prenosi signal, pa up/up status ostaje prikazan — ali nesklad u načinu slanja/primanja (full naspram half) izaziva kolizije i greške na strani koja koristi half-duplex, uzrokujući retransmisije i drastičan pad efektivnog protoka bez potpunog prekida veze.

Tema 4 – Pogrešna IP adresa, maska ili gateway

1. Jednostavno objašnjenje

Tri najosnovnija parametra IP konfiguracije (Modul 4) — adresa, maska, gateway — moraju svi biti tačni; greška u bilo kom od njih izaziva prepoznatljive, ali različite simptome.

2. Stručno objašnjenje

Pogrešna IP adresa (npr. van očekivane podmreže, ili duplikat, Tema 15) sprečava komunikaciju čak i unutar lokalne mreže. Pogrešna maska (npr. /25 umesto /24) izaziva da uređaj pogrešno izračuna koji su uređaji „lokalni" — može komunicirati sa nekim uređajima na istom fizičkom segmentu, ali ne sa drugima, jer pogrešno pokušava da ih dosegne preko gateway-a (ili obrnuto). Pogrešan gateway (Modul 4, 11) sprečava komunikaciju van lokalne podmreže, dok komunikacija unutar iste podmreže i dalje radi normalno — ključan dijagnostički signal koji odmah sužava problem na gateway, ne na celu IP konfiguraciju.

3. Primer iz svakodnevnog života

Pogrešna maska je kao pogrešna procena granica sopstvenog naselja — mislite da je susedna kuća „daleko" (van naselja) kada je zapravo blizu, pa nepotrebno šaljete pismo preko glavne pošte (gateway) umesto direktno komšiji.

4. Primer iz poslovnog IT okruženja

Novi zaposleni sa ručno (statički) podešenim laptopom (greška u kopiranju IP konfiguracije od kolege) ima ispravnu IP adresu i masku, ali gateway adresu kolege koja je u drugoj podmreži — rezultat: može da pristupi svim uređajima u sopstvenoj kancelariji (ista podmreža), ali ne i internetu ili resursima u drugim delovima firme (van podmreže) — simptom koji odmah ukazuje na gateway kao verovatan uzrok, pre bilo kakve dalje dijagnostike.

5. Praktična vežba / napomena

Na bilo kom klijentu iz ranijih vežbi, pokrenite ipconfig /all (Windows, Modul 17) ili ip addr show (Linux, Modul 18) i ručno proverite da adresa/maska/gateway čine logički konzistentnu celinu (gateway mora biti u istoj podmreži kao adresa uređaja).

6. Najčešće greške

  • Kopiranje IP konfiguracije sa drugog uređaja bez izmene svih polja — čest uzrok nekonzistentne konfiguracije (npr. tuđa adresa uz sopstveni gateway, ili obrnuto).
  • Zaboravljanje da je „radi lokalno, ne radi van lokalne mreže" specifičan, dijagnostički koristan simptom koji odmah upućuje na gateway, ne generički signal „nešto ne valja".

7. Pitanje za proveru znanja

P: Ako uređaj može da komunicira sa svim uređajima u sopstvenoj lokalnoj mreži, ali ne i sa bilo čim van nje, koji je najverovatniji uzrok? O: Pogrešan (ili nedostajući) default gateway — komunikacija unutar lokalne podmreže ne zahteva gateway, dok svaka komunikacija van nje zavisi upravo od ispravne gateway konfiguracije.

Tema 5 – DHCP problemi

1. Jednostavno objašnjenje

Kada DHCP (Modul 13) ne radi ispravno, klijent ili uopšte ne dobija adresu, dobija pogrešnu adresu, ili dobija adresu koja se sukobljava sa nekim drugim uređajem.

2. Stručno objašnjenje

Tipični DHCP problemi: Nema odgovora — klijent ostaje na APIPA adresi (169.254.x.x, Modul 4) jer DHCP server nije dostupan (ugašen, DHCP relay/ip helper-address nedostaje na udaljenoj mreži, Modul 13), ili je scope iscrpljen (sve adrese već dodeljene); Pogrešan opseg/opcije — klijent dobija adresu, ali sa pogrešnim gateway-om/DNS serverom (greška u konfiguraciji default-router/dns-server opcija); Konflikt adresa (Tema 15) — DHCP server dodeljuje adresu koja je već u upotrebi (npr. statički dodeljena nekom drugom uređaju bez odgovarajuće excluded-address, Modul 13). Dijagnostika: ipconfig /all/ip addr show na klijentu da se potvrdi tip adrese (DHCP naspram APIPA naspram statička); show ip dhcp binding na Cisco DHCP serveru (Modul 13) ili Get-DhcpServerv4Lease na Windows Server (Modul 17) da se potvrdi da server uopšte pokušava dodelu.

3. Primer iz svakodnevnog života

DHCP problem je kao nova zgrada u kojoj uprava (DHCP server) ili ne postoji (nema odgovora), ili greškom dodeljuje broj stana koji je već zauzet (konflikt), ili tačan broj stana ali pogrešnu adresu zgrade na papiru (pogrešne opcije).

4. Primer iz poslovnog IT okruženja

Nakon planiranog restarta rutera koji služi kao DHCP server (Modul 13), više korisnika istovremeno prijavljuje „nema interneta" — IT podrška proverava ipconfig /all na jednom od pogođenih računara, vidi APIPA adresu, i odmah zaključuje da DHCP server (ruter) verovatno još uvek nije potpuno završio pokretanje, umesto da posumnja na desetine pojedinačnih problema sa svakim računarom posebno.

5. Praktična vežba / napomena

U bilo kojoj Packet Tracer topologiji iz Modula 13, namerno isključite DHCP server i posmatrajte kako se IP Configuration na klijentu menja nakon ipconfig /release i /renew.

6. Najčešće greške

  • Pretpostavka da je problem specifičan za jedan računar kada je zapravo DHCP server u pitanju — provera da li je problem izolovan ili opšti (više korisnika odjednom) je ključan prvi korak (isti princip kao Tema 1).
  • Zaboravljanje da proveri DHCP relay (ip helper-address) kao mogući uzrok kada klijent na udaljenoj mreži ne dobija adresu, dok klijenti na mreži samog DHCP servera rade normalno.

7. Pitanje za proveru znanja

P: Kako biste razlikovali „DHCP server je potpuno nedostupan" od „DHCP server dodeljuje pogrešne opcije" samo na osnovu ipconfig /all izlaza klijenta? O: Ako je klijent dobio APIPA adresu (169.254.x.x), DHCP server uopšte nije odgovorio. Ako je klijent dobio adresu iz očekivanog opsega, ali sa pogrešnim gateway-om/DNS serverom, server je odgovorio, ali sa pogrešno konfigurisanim opcijama u samom pool-u/scope-u.

Tema 6 – DNS problemi

1. Jednostavno objašnjenje

Kada DNS (Modul 13) ne radi ispravno, uređaj može imati potpuno ispravnu IP konfiguraciju i mrežnu povezanost, ali i dalje ne može da pristupi resursima preko imena.

2. Stručno objašnjenje

Tipični DNS problemi: Nema rezolucije — nslookup/dig (Moduli 17-19) ne vraća odgovor, uzrok može biti pogrešan DNS server u konfiguraciji klijenta, DNS server je nedostupan, ili firewall blokira port 53; Pogrešan zapis — DNS vraća odgovor, ali sa zastarelom ili netačnom IP adresom (visok TTL sa starim podatkom nakon nedavne izmene, Modul 13); Spor odgovor — rezolucija tehnički uspeva, ali sa neuobičajenim kašnjenjem, vidljivim kroz dig Query time polje (Modul 18-19), često uzrokovano udaljenim/preopterećenim DNS serverom. Ključna dijagnostička tehnika (Tema 1 princip): prvo potvrditi IP povezanost (ping ka IP adresi direktno, zaobilazeći DNS), zatim odvojeno testirati DNS (nslookup/dig) — ako IP ping radi, a DNS ne, problem je definitivno izolovan na DNS sloj.

3. Primer iz svakodnevnog života

DNS problem je kao ispravan telefonski sistem (mreža radi) sa pokvarenim ili zastarelim imenikom (DNS) — možete pozvati broj direktno ako ga znate (IP adresa), ali ne možete pronaći taj broj tražeći po imenu.

4. Primer iz poslovnog IT okruženja

Zaposleni prijavljuje da ne može da pristupi internom portalu preko imena, iako kolega pored njega može — IT podrška prvo proverava DNS konfiguraciju pogođenog uređaja (ipconfig /all) i otkriva da je nedavno (greškom) ručno postavljen javni DNS server (8.8.8.8) umesto internog Domain Controller-a (Modul 17, Tema 11) — javni DNS nema pojma o internom imenu, pa rezolucija propada baš i samo za tog jednog korisnika.

5. Praktična vežba / napomena

Na bilo kom klijentu, namerno promenite DNS server na netačnu vrednost i uporedite ponašanje ping <ime> (propada, jer prvo pokušava DNS rezoluciju) naspram ping <IP adresa direktno> (i dalje radi) — ova razlika je upravo dijagnostička tehnika opisana iznad.

6. Najčešće greške

  • Testiranje samo preko imena (ping google.com) i zaključivanje „internet ne radi" kada je zapravo samo DNS neispravan, dok bi IP povezanost (ping 8.8.8.8) i dalje radila savršeno.
  • Zanemarivanje TTL vrednosti pri sumnji na „zastareo" DNS odgovor — dugačak TTL objašnjava zašto se stara vrednost i dalje vraća neko vreme nakon legitimne izmene na serveru.

7. Pitanje za proveru znanja

P: Koji je prvi dijagnostički korak kada sumnjate da je problem specifično DNS, a ne opšta mrežna povezanost? O: Testirati ping (ili sličnu komunikaciju) direktno ka IP adresi odredišta, zaobilazeći DNS — ako to uspe dok pristup preko imena ne uspeva, problem je definitivno izolovan na DNS rezoluciju.

Tema 7 – VLAN i trunk problemi

1. Jednostavno objašnjenje

Kada su VLAN-ovi (Modul 9) ili trunk veze (Modul 9-10) pogrešno konfigurisane, uređaji koji bi trebalo da komuniciraju ostaju izolovani, ili obrnuto — uređaji koji bi trebalo da budu odvojeni mogu neočekivano da komuniciraju.

2. Stručno objašnjenje

Tipični VLAN/trunk problemi: Pogrešna dodela porta — access port dodeljen pogrešnom VLAN-u (switchport access vlan <broj>, Modul 9), izolujući uređaj od očekivane mreže; Trunk ne prenosi očekivan VLAN — switchport trunk allowed vlan lista (Modul 9) ne uključuje potreban VLAN, sprečavajući saobraćaj tog VLAN-a da uopšte prođe kroz trunk; Native VLAN mismatch — dva kraja trunk veze imaju različito podešen native VLAN (Modul 9, 16), izazivajući greške i, potencijalno, VLAN hopping rizik (Modul 16); STP blokira port (Modul 10) — port koji bi trebalo da prosleđuje saobraćaj je u blocking stanju usled Spanning Tree topologije, često pogrešno protumačeno kao „port ne radi" umesto ispravnog STP ponašanja. Dijagnostika: show vlan brief (potvrda dodele portova), show interfaces trunk (potvrda allowed VLAN liste i native VLAN na oba kraja), show spanning-tree (potvrda da port nije neočekivano u blocking stanju).

3. Primer iz svakodnevnog života

Pogrešna VLAN dodela je kao slučajno stavljanje pošte za Odeljenje A u pregradak Odeljenja B — pošta fizički stiže u zgradu (fizička veza radi), ali završava na pogrešnom mestu (pogrešna logička mreža).

4. Primer iz poslovnog IT okruženja

Nakon zamene sviča, zaposleni u Odeljenju Prodaje iznenada ne mogu da pristupe deljenom serveru koji su ranije koristili — dijagnostika pomoću show vlan brief na novom svič-u otkriva da su njihovi portovi greškom dodeljeni VLAN-u 10 (podrazumevani VLAN na novom uređaju) umesto ispravnom VLAN-u 20 (Prodaja) korišćenom u ostatku mreže — čest previd prilikom zamene opreme bez pažljivog kopiranja postojeće konfiguracije.

5. Praktična vežba / napomena

U bilo kojoj VLAN topologiji iz Modula 9-10, pokrenite show vlan brief, show interfaces trunk, i show spanning-tree i uporedite dobijene informacije sa očekivanom, dokumentovanom konfiguracijom.

6. Najčešće greške

  • Zaboravljanje da proveri show interfaces trunk (allowed VLAN listu) kada saobraćaj konkretnog VLAN-a ne prolazi kroz trunk, fokusirajući se samo na dodelu access portova.
  • Tumačenje STP blocking stanja porta kao kvara — to je namerno, ispravno ponašanje STP-a (Modul 10) koje sprečava petlje, ne greška koju treba „ispraviti" bez razumevanja topologije.

7. Pitanje za proveru znanja

P: Koje tri show komande biste koristile da sistematski proverite VLAN/trunk konfiguraciju kada sumnjate na problem tog tipa? O: show vlan brief (dodela portova VLAN-ovima), show interfaces trunk (allowed VLAN lista i native VLAN na trunk vezama), show spanning-tree (da li je neki relevantan port neočekivano u blocking stanju).

Tema 8 – Problemi sa rutiranjem

1. Jednostavno objašnjenje

Kada rutiranje (Moduli 11-12) ne radi ispravno, paketi ili uopšte ne stižu do odredišne mreže, ili stižu pogrešnim, neefikasnim putem.

2. Stručno objašnjenje

Tipični problemi sa rutiranjem: Nedostajuća ruta — show ip route (Modul 11) ne prikazuje putanju ka odredišnoj mreži, izazivajući „Destination unreachable" — uzrok može biti nedostajuća statička ruta, ili dinamički protokol (OSPF, Modul 12) koji nije ispravno konfigurisan (pogrešan network iskaz, pogrešna area, susedi se ne formiraju); Pogrešna administrativna udaljenost (Modul 11) — kada su statička i dinamička ruta ka istoj mreži obe prisutne, ruter bira onu sa manjom AD vrednošću, što ponekad nije ono što administrator zapravo želi; Asimetrično rutiranje — saobraćaj ide jednim putem u jednom smeru, a drugim u povratnom smeru, ponekad izazivajući probleme sa stateful firewall-ima (Modul 16) koji ne vide kompletnu konverzaciju. Dijagnostika: show ip route (potvrda postojanja i izvora rute — statička, OSPF, itd.), traceroute/tracert/tracepath (Moduli 15, 17, 18) da se vidi tačno gde putanja prestaje da napreduje ili skreće neočekivano.

3. Primer iz svakodnevnog života

Nedostajuća ruta je kao nepostojanje puta na mapi ka određenom gradu — bez obzira koliko je vaše sopstveno vozilo (konfiguracija) ispravno, fizički ne postoji put kojim biste stigli.

4. Primer iz poslovnog IT okruženja

Nakon dodavanja nove podmreže u firmi, korisnici na toj mreži ne mogu da pristupe ostatku firme — show ip route na centralnom ruteru potvrđuje da ruta ka novoj podmreži uopšte ne postoji, jer administrator koji je dodao mrežu na jednom ruteru zaboravio da doda odgovarajuću statičku rutu (ili OSPF network iskaz) na susednom ruteru koji bi trebalo da je prosleđuje dalje.

5. Praktična vežba / napomena

U bilo kojoj multi-router topologiji iz Modula 11-12, namerno uklonite jednu statičku rutu (ili OSPF network iskaz) i posmatrajte kako traceroute sa udaljenog uređaja prestaje da napreduje tačno na ruteru kome ta ruta nedostaje.

6. Najčešće greške

  • Zaboravljanje da proveri oba smera rutiranja — ruta može postojati u jednom smeru, ali nedostajati u povratnom, izazivajući asimetrične ili potpuno neuspešne konekcije zavisno od toga ko inicira komunikaciju.
  • Mešanje „ruta ne postoji" (Destination unreachable) sa „ruta postoji, ali je pogrešna/neefikasna" (sporiji put, ili put preko pogrešnog linka) — različiti simptomi, različita dijagnostika.

7. Pitanje za proveru znanja

P: Zašto traceroute posebno koristan alat za dijagnostiku problema sa rutiranjem, u odnosu na sam show ip route? O: show ip route pokazuje samo lokalnu routing tabelu jednog uređaja; traceroute pokazuje kompletnu putanju kroz više uređaja, otkrivajući tačno koji ruter na putu nema ispravnu rutu ili gde putanja neočekivano skreće — informacija koju lokalna routing tabela jednog uređaja sama po sebi ne može pružiti.

Tema 9 – Problemi uzrokovani ACL-om

1. Jednostavno objašnjenje

Pogrešno napisana ili pogrešno primenjena pristupna lista (Modul 16) može blokirati legitiman saobraćaj koji bi trebalo da prođe, ili propustiti saobraćaj koji bi trebalo da bude blokiran.

2. Stručno objašnjenje

Tipični ACL problemi: Redosled pravila — ACL se obrađuje odozgo nadole, prvo pravilo koje odgovara se primenjuje (Modul 16); opštije deny pravilo postavljeno pre specifičnijeg permit pravila sprečava da ono drugo pravilo ikada bude dostignuto; Implicitni deny any na kraju — zaboravljanje da svaka ACL završava implicitnim odbijanjem svega neeksplicitno dozvoljenog, blokirajući saobraćaj koji administrator nije nameravao da blokira; Pogrešan smer primene (in naspram out, Modul 16) — ACL primenjena u pogrešnom smeru na interfejsu filtrira sasvim drugačiji saobraćaj od namere; Pogrešna wildcard maska (Modul 12, 16) — greška u wildcard notaciji obuhvata pogrešan (širi ili uži) opseg adresa od namere. Dijagnostika: show access-lists (Modul 16) prikazuje brojače pogodaka (matches) po pravilu — pravilo sa neočekivano visokim ili niskim brojem pogodaka odmah ukazuje gde tražiti problem.

3. Primer iz svakodnevnog života

Pogrešan redosled ACL pravila je kao pravilnik u kome je opšte pravilo „niko ne ulazi" napisano pre izuzetka „osim zaposlenih" — ako se pravila čitaju po redosledu i prvo se primeni ono koje odgovara, izuzetak nikad neće biti dostignut.

4. Primer iz poslovnog IT okruženja

Nakon dodavanja novog pravila u postojeću ACL da se dozvoli pristup novom serveru, administrator primećuje da pristup i dalje ne radi — show access-lists otkriva da novo, specifično permit pravilo ima veći redni broj (sequence number) od postojećeg, opštijeg deny pravila koje već odgovara istom saobraćaju — novo pravilo se nikad ne dostiže jer je starije, opštije pravilo obrađeno prvo.

5. Praktična vežba / napomena

U bilo kojoj ACL konfiguraciji iz Modula 16, pokrenite show access-lists pre i posle generisanja očekivanog saobraćaja, i uporedite promenu brojača pogodaka po svakom pravilu da potvrdite koje pravilo zaista „hvata" taj saobraćaj.

6. Najčešće greške

  • Dodavanje novog pravila na kraj postojeće ACL bez razmišljanja o tome da li ga neko ranije, opštije pravilo već „presreće".
  • Zaboravljanje implicitnog deny any — česta greška je pretpostavka da će sav saobraćaj koji nije eksplicitno pomenut biti dozvoljen, kada je zapravo obrnuto.

7. Pitanje za proveru znanja

P: Kako show access-lists brojač pogodaka pomaže u dijagnostici da li je ACL uzrok problema? O: Ako pravilo za koje se očekuje da dozvoli saobraćaj ima nula pogodaka dok se problem dešava, to znači da taj saobraćaj nikad ne dostiže to pravilo (verovatno ga je presrelo neko ranije pravilo) — brojači direktno pokazuju koje pravilo zaista obrađuje dati saobraćaj, bez nagađanja.

Tema 10 – Problemi uzrokovani NAT-om

1. Jednostavno objašnjenje

Pogrešno konfigurisan NAT (Modul 13) može sprečiti da interni uređaji pristupe internetu, ili da spoljni korisnici pristupe internim serverima koji bi trebalo da budu javno dostupni.

2. Stručno objašnjenje

Tipični NAT problemi: Nedostajuće ip nat inside/outside oznake (Modul 13) — NAT konfiguracija postoji, ali se nikad ne primenjuje jer ruter ne zna koji interfejs je „unutra", a koji „spolja"; Pogrešan ili nedostajući ACL u ip nat inside source list (Modul 13) — PAT/dynamic NAT ne prevodi saobraćaj jer izvorišna mreža nije uključena u referenciranu ACL; Static NAT sa netačnom internom adresom — javna adresa je mapirana na pogrešnu, zastarelu, ili nepostojeću internu adresu (npr. nakon promene IP adrese servera bez ažuriranja NAT mapiranja); Preklapanje sa postojećim javnim adresama — retko, ali moguće kada je NAT pool pogrešno definisan. Dijagnostika: show ip nat translations (Modul 13) — ako se očekivan prevod uopšte ne pojavljuje nakon generisanog saobraćaja, problem je u samoj NAT konfiguraciji ili nedostajućim inside/outside oznakama; show ip nat statistics za brz pregled ukupnog broja aktivnih prevoda.

3. Primer iz svakodnevnog života

NAT problem je kao pogrešno podešena centrala firme (Modul 13 analogija) koja ne zna koje su unutrašnje linije, a koje spoljna — pozivi se jednostavno nikad ne prevode ispravno u bilo kom smeru.

4. Primer iz poslovnog IT okruženja

Nakon migracije internog veb servera na novu IP adresu (u sklopu proširenja mreže), spoljni korisnici iznenada ne mogu da pristupe javnom sajtu firme — dijagnostika show ip nat translations pokazuje da static NAT mapiranje i dalje pokazuje na staru internu adresu servera, jer niko nije ažurirao NAT konfiguraciju nakon promene adrese servera — klasičan primer zaboravljene zavisnosti između dva odvojena koraka konfiguracije.

5. Praktična vežba / napomena

U bilo kojoj NAT konfiguraciji iz Modula 13, namerno uklonite ip nat inside oznaku sa internog interfejsa i posmatrajte kako show ip nat translations prestaje da prikazuje nove prevode uprkos i dalje ispravnoj ip nat inside source konfiguraciji.

6. Najčešće greške

  • Fokusiranje isključivo na ip nat inside source/static komande, zaboravljajući da NAT ne radi bez odgovarajućih ip nat inside/outside oznaka na interfejsima.
  • Zaboravljanje da ažurira static NAT mapiranje nakon promene interne IP adrese servera na koji se ono odnosi.

7. Pitanje za proveru znanja

P: Šta show ip nat translations pokazuje ako je NAT konfiguracija (source list, static mapiranja) potpuno ispravna, ali ip nat inside/outside oznake nedostaju na interfejsima? O: Prazna tabela (ili tabela bez novih prevoda) — bez inside/outside oznaka, ruter ne zna gde se granica NAT-a nalazi, pa nikad ne primenjuje postojeću NAT konfiguraciju na stvaran saobraćaj, bez obzira na to koliko je ta konfiguracija sama po sebi ispravna.

Tema 11 – Wi-Fi problemi

1. Jednostavno objašnjenje

Bežični problemi (Modul 14) mogu poticati od slabog signala, pogrešne lozinke, smetnji, ili pogrešnog kanala — svaki sa drugačijim simptomom koji upućuje na uzrok.

2. Stručno objašnjenje

Tipični Wi-Fi problemi: Slab signal (Modul 14) — nizak RSSI zbog udaljenosti/prepreka, manifestuje se kao spora, nestabilna veza, ne potpun prekid; Problem autentifikacije — pogrešna lozinka ili nepoklapanje bezbednosnog standarda (WPA2 naspram WPA3) sprečava povezivanje pre DHCP faze, uređaj nikad ne dobija IP adresu; Smetnje/interferencija (Modul 14) — ko-kanalna interferencija sa susednim mrežama ili ne-Wi-Fi izvori (mikrotalasne, Bluetooth), manifestuje se kao povremeni, teško ponovljivi problemi; Pogrešan kanal/preopterećenje — previše uređaja/access point-a na istom kanalu u gustom okruženju (Modul 14, Tema 12) degradira performanse svima. Sistematska dijagnostika (Modul 14, Tema 13): prvo proveriti da li se uređaj uopšte povezuje na SSID (autentifikacija), zatim proveriti RSSI/signal (kvalitet veze), zatim proveriti DHCP/IP konfiguraciju nakon uspešnog povezivanja — problem se izoluje na tačno jedan od ova tri sloja.

3. Primer iz svakodnevnog života

Wi-Fi dijagnostika je kao redosled provere zašto ne možete da uđete u zgradu preko interfona — prvo da li vas uopšte puste unutra (autentifikacija), zatim da li se dobro čujete kroz interfon (signal), zatim da li vas neko unutra dočeka sa pravim uputstvima (DHCP).

4. Primer iz poslovnog IT okruženja

Zaposleni u konferencijskoj sali prijavljuje povremeno, isprekidano isključivanje sa Wi-Fi mreže tokom sastanaka — IT tim otkriva da soba ima staru mikrotalasnu pećnicu u susednoj kuhinji koja se koristi tačno u vreme pauza za ručak, direktno preklapajući se sa 2,4 GHz Wi-Fi kanalom access point-a te sale (Modul 14, Tema 10) — rešenje je premeštanje access point-a ili prebacivanje korisnika na 5 GHz opseg.

5. Praktična vežba / napomena

Sledeći put kada iskusite Wi-Fi problem na sopstvenom uređaju, primenite tačan redosled iz Modula 14 (Tema 13): proverite da li ste uopšte povezani na SSID, zatim proverite RSSI, zatim proverite IP konfiguraciju — identifikujte tačno na kom koraku se problem manifestuje.

6. Najčešće greške

  • Pretpostavka da je „loš signal" uvek uzrok Wi-Fi problema, zanemarujući mogućnost problema sa autentifikacijom ili DHCP-om koji se javljaju čak i uz odličan signal.
  • Nedovoljno razlikovanje „ne mogu da se povežem na Wi-Fi uopšte" (autentifikacija) od „povezan sam, ali nemam internet" (DHCP/rutiranje posle uspešne Wi-Fi konekcije) — dva potpuno različita sloja problema.

7. Pitanje za proveru znanja

P: Ako se uređaj uspešno povezuje na Wi-Fi mrežu (prikazuje „Connected"), ali nema pristup internetu, na kom sloju sistematske dijagnostike (autentifikacija, signal, DHCP/IP) je problem definitivno isključen, a na kom treba tražiti dalje? O: Autentifikacija je definitivno uspešna (uređaj je povezan) — problem treba tražiti u DHCP/IP konfiguraciji (da li je uređaj dobio validnu adresu, gateway, DNS) ili u rutiranju/internet vezi posle uspešnog povezivanja na samu bežičnu mrežu.

Tema 12 – Problemi sa pristupom internetu

1. Jednostavno objašnjenje

Kada „internet ne radi" za celu lokaciju (ne samo jednog korisnika), problem je često van kontrole internog IT tima — na strani ISP-a ili WAN veze (Modul 15).

2. Stručno objašnjenje

Prvi dijagnostički korak (princip iz Teme 1) je utvrditi da li je problem izolovan (jedan uređaj) ili opšti (cela lokacija) — ako je opšti, sumnja se odmah usmerava na granični ruter/modem (Modul 15) i vezu ka ISP-u, ne na pojedinačne klijentske konfiguracije. Tipični uzroci: ISP prekid (van kontrole internog tima, potvrđuje se proverom da li modem/ruter uopšte ima vezu ka ISP-u, npr. status LED na modemu, Tema 2 princip primenjen na WAN opremu); Granični ruter/firewall problem — konfiguracija (NAT, Tema 10; ACL, Tema 9) na graničnom uređaju sprečava saobraćaj; WAN link degradacija (Modul 15) — visoka latencija/packet loss na WAN vezi (dijagnostika preko pathping/Wireshark, Moduli 17, 19) čini internet „tehnički dostupnim, ali neupotrebljivo sporim", različit simptom od potpunog prekida.

3. Primer iz svakodnevnog života

Problem sa ISP-om je kao prekid vodovoda na nivou cele ulice — proveravanje sopstvene slavine (klijentska konfiguracija) je beskorisno ako problem uopšte nije unutar vaše kuće.

4. Primer iz poslovnog IT okruženja

Cela kancelarija prijavljuje gubitak interneta istovremeno — IT administrator prvo proverava status LED na graničnom modemu/ruteru (Tema 2 princip) i utvrđuje da nema veze ka ISP-u uopšte, potvrđujući da je problem van interne mreže — umesto trošenja vremena na proveru pojedinačnih klijentskih računara, odmah kontaktira ISP podršku sa konkretnim, već prikupljenim dokazom (status LED, vreme prekida).

5. Praktična vežba / napomena

Sledeći put kada imate problem sa internetom kod kuće, prvo proverite status LED indikatore na modemu/ruteru (obično označavaju status veze ka ISP-u posebno od statusa lokalne mreže) pre bilo kakve dalje dijagnostike na sopstvenim uređajima.

6. Najčešće greške

  • Trošenje vremena na detaljnu dijagnostiku pojedinačnih klijentskih uređaja kada je problem već očigledno opšti (svi korisnici odjednom) — princip „izolovan naspram opšti problem" (Tema 1) trebalo bi odmah da usmeri fokus na granični uređaj/ISP.
  • Mešanje „nema veze uopšte" sa „veza postoji, ali je jako spora/nestabilna" — potonje zahteva merenje latencije/packet loss-a (Modul 15), ne samo proveru da li veza „postoji".

7. Pitanje za proveru znanja

P: Zašto je „da li je problem izolovan na jednog korisnika ili pogađa celu lokaciju" često prvo pitanje pri dijagnostici problema sa internetom? O: Odgovor odmah usmerava dalju dijagnostiku — izolovan problem ukazuje na klijentsku konfiguraciju/lokalnu mrežu, dok opšti problem (svi korisnici odjednom) ukazuje na granični ruter, ISP vezu, ili WAN link, potpuno drugačiji deo infrastrukture za proveru.

Tema 13 – Mrežni aspekti problema sa serverima

1. Jednostavno objašnjenje

Kada je „server nedostupan", problem može biti u samom serveru (aplikacija, hardver), ili u mreži između klijenta i servera — razlikovanje ova dva je ključan prvi korak.

2. Stručno objašnjenje

Sistematska provera (kombinujući Module 17-19): (1) ping ka IP adresi servera — potvrđuje osnovnu mrežnu povezanost, nezavisno od bilo koje aplikacije koja na njemu radi; (2) provera da li konkretan port/servis odgovara — Test-NetConnection -Port (Windows, Modul 17) ili nc -zv/ss -tulpn sa same mašine (Linux, Modul 18) — razlikuje „server je potpuno nedostupan" od „server radi, ali konkretan servis na njemu ne"; (3) ako port lokalno „sluša" ali nije dostupan spolja, sumnja pada na firewall (UFW, Modul 16/18, ili ACL, Tema 9) između klijenta i servera; (4) Wireshark analiza (Modul 19) TCP handshake-a otkriva da li SYN uopšte dobija odgovor. Ova sekvenca precizno razdvaja mrežni uzrok (nedostupnost, firewall) od serverskog/aplikativnog uzroka (servis pao, spora obrada zahteva), izbegavajući pogrešno angažovanje mrežnog tima za problem koji je zapravo u aplikaciji, ili obrnuto.

3. Primer iz svakodnevnog života

Razlikovanje mrežnog od serverskog problema je kao razlikovanje „telefonska linija ne radi" (mreža) od „osoba na drugom kraju ne odgovara na poziv koji uredno zvoni" (server/aplikacija) — oba zvuče kao „ne mogu da ih dobijem", ali zahtevaju potpuno različitu reakciju.

4. Primer iz poslovnog IT okruženja

Korisnici prijavljuju da interna aplikacija „ne radi" — mrežni tim proverava ping ka serveru (uspeva) i Test-NetConnection -Port 443 (takođe uspeva, port sluša) — ovo definitivno isključuje mrežu kao uzrok i usmerava dalju istragu ka samom serverskom timu/aplikaciji (možda je aplikacija „zaglavljena", baza podataka nedostupna, itd.), umesto da mrežni tim nastavi da traži nepostojeći mrežni uzrok.

5. Praktična vežba / napomena

Za bilo koji server iz prethodnih laboratorijskih vežbi (Modul 17-18), provežbajte tačan redosled: ping, zatim provera konkretnog porta lokalno, zatim provera istog porta sa drugog uređaja — primetite na kom koraku bi se svaki od uobičajenih uzroka (server ugašen, firewall blokira, aplikacija pala) manifestovao drugačije.

6. Najčešće greške

  • Prijava „mreža ne radi" od strane serverskog tima bez ijedne osnovne provere (ping) koja bi odmah pokazala da li je pretpostavka uopšte tačna.
  • Zaboravljanje da testira port lokalno na samom serveru pre nego što se zaključi da je problem „mrežni" — ako servis ni lokalno ne sluša, problem je definitivno u samoj aplikaciji, ne u mreži.

7. Pitanje za proveru znanja

P: Koja sekvenca provera precizno razdvaja mrežni uzrok nedostupnosti servera od serverskog/aplikativnog uzroka? O: (1) ping ka IP adresi servera (osnovna mrežna povezanost); (2) provera da li konkretan port sluša lokalno na serveru; (3) provera da li je isti port dostupan spolja, sa drugog uređaja — nepoklapanje između (2) i (3) ukazuje na mrežni/firewall problem, dok neuspeh već u (2) ukazuje na sam server/aplikaciju.

Tema 14 – Problemi sa mrežnim štampačima

1. Jednostavno objašnjenje

Mrežni štampači su česti izvor prijava korisnika, a uzroci su gotovo uvek isti osnovni mrežni problemi (IP konfiguracija, DHCP, fizička veza) primenjeni na specifičan uređaj koji korisnici retko povezuju sa „mrežnim" problemom.

2. Stručno objašnjenje

Tipični problemi sa mrežnim štampačima: Promenjena IP adresa — štampač konfigurisan preko DHCP-a (umesto statičke adrese) dobija novu adresu nakon restarta (posebno ako lease istekne, Modul 13), dok su klijenti i dalje konfigurisani da štampaju na staru adresu — klasično rešenje je dodela statičke adrese (ili DHCP rezervacije vezane za MAC adresu) štampačima, jer se retko selu i korisno je da im adresa bude predvidljiva; Fizička/VLAN izolacija (Teme 2, 7) — štampač na drugom VLAN-u ili fizički segmentu bez ispravno konfigurisanog rutiranja između njega i klijenata; Firewall/ACL blokada (Modul 16, Tema 9) — port za štampanje (npr. 9100 za raw printing, ili 631 za IPP) blokiran između klijentske i printer mreže. Dijagnostika sledi identičan obrazac kao za bilo koji drugi mrežni uređaj (Teme 4-10) — štampač je, sa mrežne tačke gledišta, samo još jedan uređaj sa IP adresom.

3. Primer iz svakodnevnog života

Problem sa promenjenom adresom štampača je kao promena broja stana bez obaveštavanja svih koji vam obično šalju poštu — pošta (podaci za štampanje) i dalje ide na staru, sada netačnu adresu.

4. Primer iz poslovnog IT okruženja

Nakon planiranog gašenja cele kancelarije preko vikenda (i restarta svih uređaja), u ponedeljak više zaposlenih prijavljuje da „štampač ne radi" — IT podrška prepoznaje obrazac (više korisnika, isti uzrok, nakon restarta opreme) i odmah proverava da li je štampač (koji je greškom ostavljen na DHCP umesto statičke adrese) dobio novu IP adresu nakon restarta, dok su klijentski računari i dalje konfigurisani da šalju poslove štampe na staru adresu — rešenje: dodeliti štampaču statičku adresu (ili DHCP rezervaciju) da se ovo više ne ponovi.

5. Praktična vežba / napomena

Za bilo koji uređaj koji igra ulogu „štampača" u vašim laboratorijskim vežbama (ili stvaran mrežni štampač ako ga imate), proverite da li koristi statičku ili DHCP adresu, i razmislite koje bi bilo bolje rešenje na osnovu principa iz ove teme.

6. Najčešće greške

  • Konfigurisanje mrežnih štampača (i drugih retko-pomerenih, ali kritičnih uređaja poput servera, mrežne opreme) preko DHCP-a bez rezervacije — direktan uzrok problema opisanog u ovoj temi.
  • Tretiranje „problema sa štampačem" kao potpuno odvojene kategorije od „mrežnih problema", umesto prepoznavanja da je to isti skup dijagnostičkih alata (IP konfiguracija, ping, port provera) primenjen na specifičan tip uređaja.

7. Pitanje za proveru znanja

P: Zašto se mrežnim štampačima (i sličnim, retko pomerenim uređajima) preporučuje statička adresa ili DHCP rezervacija, umesto obične DHCP dodele? O: Uređaji poput štampača se retko fizički pomeraju, ali klijentski računari ih često referenciraju po fiksnoj IP adresi u sopstvenim podešavanjima — ako štampač dobije novu adresu putem obične DHCP dodele (npr. nakon restarta ili isteka lease-a), svi klijenti koji su konfigurisani sa starom adresom prestaju da mogu da mu pristupe, dok statička adresa (ili rezervacija) garantuje da adresa ostaje nepromenjena.

Tema 15 – Duple IP adrese

1. Jednostavno objašnjenje

Kada dva uređaja na istoj mreži imaju istu IP adresu, oba trpe nepredvidive, isprekidane probleme — jedan od najtežih problema za dijagnostikovati upravo zbog svoje nepredvidivosti.

2. Stručno objašnjenje

Konflikt IP adresa nastaje kada dva uređaja dele istu adresu — uzroci: statička adresa slučajno dodeljena u opsegu koji DHCP server (Modul 13) i dalje aktivno koristi (bez odgovarajuće excluded-address); dva DHCP servera sa preklapajućim opsezima (bez DHCP snooping-a, Modul 16, koji bi ovo sprečio na nivou infrastrukture); ili ručna greška u statičkoj konfiguraciji dva različita uređaja. Simptomi su isprekidani i zbunjujući — oba uređaja povremeno rade normalno (kada je „njihov red" u ARP tabelama okolnih uređaja, Modul 2), a povremeno ne, zavisno od toga koji je od dva uređaja poslednji odgovorio na ARP upit za tu adresu. Windows sistemi (Modul 17) često eksplicitno upozoravaju „IP address conflict" u sistemskim obaveštenjima; na Linux/Cisco opremi, dijagnostika zahteva proveru arp -a/show ip arp i uočavanje da se MAC adresa za istu IP adresu menja tokom vremena — jasan, definitivan znak konflikta.

3. Primer iz svakodnevnog života

Konflikt IP adresa je kao dva stana sa istim brojem u istoj zgradi — pošta (podaci) povremeno stiže jednom, povremeno drugom stanaru, potpuno nepredvidivo i zbunjujuće za oba, zavisno od toga ko je poslednji „prijavio" taj broj poštaru.

4. Primer iz poslovnog IT okruženja

Dva korisnika istovremeno prijavljuju da im se veza „povremeno gasi i pali" bez ikakvog očiglednog obrasca — IT tim proverava arp -a na oba uređaja i primećuje da oba imaju istu IP adresu, sa MAC adresama koje se u ARP tabelama okolnih uređaja naizmenično menjaju — potvrđujući konflikt nastao jer je jedan od njih ručno (statički) konfigurisan adresom koja je slučajno unutar aktivnog DHCP opsega.

5. Praktična vežba / napomena

Ako imate mogućnost u laboratorijskom okruženju (Packet Tracer ili VirtualBox), namerno postavite dva uređaja na istu statičku IP adresu i posmatrajte upozorenja/ponašanje koje se javlja (Windows posebno eksplicitno prijavljuje ovaj tip konflikta).

6. Najčešće greške

  • Tretiranje isprekidanog, „povremenog" problema kao manje ozbiljnog ili teže dijagnostikovanog od potpunog prekida — konflikt adresa je upravo ovakav, podmukao tip problema koji se lako pogrešno protumači kao „nestabilna mreža" umesto konkretnog, rešivog uzroka.
  • Zaboravljanje da doda excluded-address (Modul 13) za sve statički dodeljene adrese unutar DHCP opsega — najčešći administrativni uzrok ovog problema.

7. Pitanje za proveru znanja

P: Zašto je konflikt IP adresa posebno težak za dijagnostikovanje u odnosu na većinu drugih mrežnih problema? O: Simptomi su isprekidani i nepredvidivi (oba uređaja povremeno rade, povremeno ne), za razliku od većine problema koji su konzistentni i ponovljivi — ovo otežava povezivanje simptoma sa uzrokom dok se eksplicitno ne proveri ARP tabela i ne primeti da se MAC adresa za istu IP adresu menja tokom vremena.

Tema 16 – Packet loss, latencija i spor protok

1. Jednostavno objašnjenje

Ove tri mere kvaliteta mreže (Modul 15) mogu izgledati slično kao „mreža je spora", ali imaju različite uzroke i zahtevaju različitu dijagnostiku i rešenja.

2. Stručno objašnjenje

Packet loss (Modul 15) — paketi se gube na putu, uzrokujući TCP retransmisije (Modul 19) i primetno degradirane performanse; dijagnostika preko ping/pathping (Moduli 17-18) i Wireshark tcp.analysis.retransmission filtera (Modul 19). Latencija — vreme putovanja paketa (Modul 15); visoka latencija sama po sebi ne znači gubitak podataka, ali degradira interaktivne aplikacije (VoIP, video pozivi, igre) više nego prenos velikih fajlova. Spor protok (throughput) — može biti posledica oba prethodna faktora, ili potpuno odvojenog uzroka poput preopterećenja linka (nedovoljna propusnost za trenutnu potražnju), duplex mismatch-a (Tema 3), ili QoS pravila (Modul 15) koja namerno ograničavaju određen tip saobraćaja. Ključna dijagnostička razlika: packet loss i latencija su mere kvaliteta puta, dok je protok mera stvarno ostvarene brzine prenosa — moguće je imati odličnu latenciju i nula packet loss-a, a i dalje spor protok (npr. usled ograničenja propusnosti linka ili QoS-a), i obrnuto.

3. Primer iz svakodnevnog života

Latencija je vreme da vaš glas stigne do sagovornika. Packet loss je kada se pojedine reči potpuno izgube usput. Protok je koliko brzo možete da prenesete veliku količinu informacija (npr. pročitate ceo dokument naglas) — sve tri mere opisuju „kvalitet komunikacije", ali na potpuno različite načine, i moguće je imati problem sa samo jednom od njih dok su ostale dve savršene.

4. Primer iz poslovnog IT okruženja

Firma koja koristi VoIP telefoniju (Modul 15) preko WAN veze sa odličnim ukupnim protokom (dovoljno propusnosti za sve potrebe) i dalje prijavljuje „loš kvalitet poziva" — dijagnostika otkriva da je jitter (varijacija latencije, Modul 15) povremeno visok usled deljenja iste veze sa velikim prenosima fajlova bez QoS prioritizacije (Modul 15) — rešenje nije povećanje propusnosti (koje već postoji u izobilju), već QoS konfiguracija koja prioritizuje glasovni saobraćaj.

5. Praktična vežba / napomena

Sledeći put kada testirate kvalitet sopstvene internet veze, obratite pažnju da li alat koji koristite meri protok (Mbps), latenciju (ms), ili packet loss (%) — svaka od ove tri mere priča drugačiji deo priče o kvalitetu veze.

6. Najčešće greške

  • Pokušaj rešavanja problema sa latencijom/jitter-om (npr. loš kvalitet VoIP poziva) povećanjem propusnosti linka — ako uzrok nije nedostatak propusnosti već QoS ili fizička udaljenost/broj skokova, dodatna propusnost neće pomoći.
  • Merenje samo protoka (npr. brzinomer) kada je stvaran problem korisnika vezan za interaktivnost (latencija/jitter kod video poziva) — protok može biti odličan dok je iskustvo i dalje loše zbog druga dva faktora.

7. Pitanje za proveru znanja

P: Zašto je moguće imati odličan ukupan protok (propusnost) mreže, a i dalje loš kvalitet VoIP poziva? O: VoIP je osetljiv prevashodno na latenciju i jitter (varijaciju latencije), ne na sirovu propusnost — visok jitter izaziva neravnomerno pristizanje glasovnih paketa i primetno lošije iskustvo, čak i kada mreža ima više nego dovoljno propusnosti (protoka) za sam obim VoIP saobraćaja.

Tema 17 – Dokumentovanje incidenta

1. Jednostavno objašnjenje

Rešavanje problema nije završeno kada mreža ponovo proradi — profesionalna praksa zahteva da se zapiše šta se desilo, kako je otkriveno, i kako je rešeno, radi budućeg učenja i odgovornosti.

2. Stručno objašnjenje

Dobra dokumentacija incidenta (nadovezuje se na Modul 16, Tema 16) sadrži: Vremenski okvir — kada je problem počeo, kada je prijavljen, kada je rešen; Simptomi — tačno šta su korisnici/monitoring sistemi prijavili, sa konkretnim detaljima (poruke o grešci, brojevi pogođenih korisnika); Dijagnostički proces — koji koraci/alati su korišćeni i šta su pokazali (čak i „ćorsokaci" koji nisu doveli do uzroka su korisni za budući referentni materijal); Osnovni uzrok (root cause) — konkretan, tehnički uzrok, ne samo simptom (npr. „nedostajala je statička ruta na R2 nakon zamene uređaja", ne samo „mreža nije radila"); Preduzete mere — tačno šta je promenjeno da se problem reši; Preventivne mere — šta će se uraditi da se spreči ponavljanje (npr. dodavanje monitoring alarma, izmena procedure zamene opreme). Ovakva dokumentacija služi i kao baza znanja za buduće, slične probleme, i kao osnova za unapređenje procesa koji su dozvolili da se problem uopšte desi.

3. Primer iz svakodnevnog života

Dokumentovanje incidenta je kao vođenje dnevnika kvarova na automobilu — sledeći put kad se pojavi sličan zvuk ili problem, prethodni zapis odmah ukazuje šta je poslednji put bio uzrok i kako je rešeno, umesto da se cela dijagnostika ponavlja od nule.

4. Primer iz poslovnog IT okruženja

Nakon što tim reši problem sa nedostupnošću internog portala (uzrokovan, u ovom primeru, isteklim TLS sertifikatom koji niko nije pratio), pišu se ne samo detalji rešenja, već i preventivna mera: automatizovano upozorenje 30 dana pre isteka bilo kog TLS sertifikata u firmi — sledeći put, problem se sprečava pre nego što se uopšte desi, umesto da se ponovo reaguje na isti tip incidenta.

5. Praktična vežba / napomena

Za poslednji mrežni problem koji ste rešili (u bilo kojoj laboratorijskoj vežbi ovog kursa), napišite kratku dokumentaciju prateći šest elemenata iz ove teme (vremenski okvir, simptomi, dijagnostički proces, osnovni uzrok, preduzete mere, preventivne mere).

6. Najčešće greške

  • Dokumentovanje samo simptoma i rešenja, preskačući osnovni uzrok (root cause) — bez pravog uzroka, budući, slični problemi se ne mogu prevenirati, samo ponovo „gase" kada se dogode.
  • Preskakanje dokumentovanja „jednostavnih" problema — čak i trivijalni problemi (labav kabl) vredni su beleženja ako se ponavljaju dovoljno često da ukažu na dublji, sistemski uzrok (npr. loš kvalitet fizičke instalacije na određenoj lokaciji).

7. Pitanje za proveru znanja

P: Zašto je „osnovni uzrok" (root cause) ključan element dokumentacije incidenta, različit od pukog opisa simptoma i primenjenog rešenja? O: Bez jasno identifikovanog osnovnog uzroka, nemoguće je preduzeti preventivne mere koje bi sprečile ponavljanje istog ili sličnog problema — dokumentacija bi samo služila za „gašenje požara" iznova i iznova, umesto za stvarno unapređenje pouzdanosti sistema tokom vremena.

Rezime modula

  • Sistematska metodologija (bottom-up, top-down, divide-and-conquer) se bira na osnovu dostupnih informacija o problemu u trenutku kada dijagnostika počinje.
  • Fizički sloj (kablovi, LED indikatori, duplex) je najčešći, a najlakše previđen uzrok problema.
  • IP konfiguracija, DHCP i DNS problemi imaju prepoznatljive, razlikujuće simptome (lokalno naspram van mreže, APIPA naspram pogrešnih opcija, IP naspram rezolucija imena).
  • VLAN/trunk, rutiranje, ACL i NAT problemi zahtevaju specifične show komande (show vlan brief, show ip route, show access-lists, show ip nat translations) da se problem precizno locira.
  • Wi-Fi, internet, server i printer problemi primenjuju isti skup osnovnih dijagnostičkih principa na specifičan kontekst svakog od njih.
  • Duple IP adrese uzrokuju isprekidane, teško dijagnostikovane simptome prepoznatljive kroz promenljivu MAC adresu u ARP tabeli.
  • Packet loss, latencija i protok su tri odvojene mere kvaliteta mreže koje zahtevaju različitu dijagnostiku i rešenja.
  • Dokumentovanje incidenta sa jasnim osnovnim uzrokom omogućava preventivne mere, ne samo rešavanje trenutnog problema.

Mermaid dijagram

graph TD
    A["Problem prijavljen"] --> B{"Izolovan ili opšti?"}
    B -->|Izolovan| C["Klijentska konfiguracija<br/>(IP, DHCP, DNS, Wi-Fi)"]
    B -->|Opšti| D["Infrastruktura<br/>(rutiranje, VLAN, ACL, NAT, ISP)"]
    C --> E["Sistematska provera<br/>sloj po sloj (Tema 1)"]
    D --> E
    E --> F["Osnovni uzrok identifikovan"]
    F --> G["Rešenje primenjeno"]
    G --> H["Dokumentovanje incidenta<br/>+ preventivne mere"]

Dodatni izvori (opciono)

  • CompTIA Network+ Troubleshooting Methodology
  • Cisco Networking Academy – Network Troubleshooting Guide