Praktični primeri – Modul 20 – Dijagnostika i rešavanje mrežnih problema

Ovaj dokument sadrži šest detaljno rešenih praktičnih primera koji objedinjuju znanje iz više prethodnih modula odjednom, i jedan integrativan poslovni scenario.

Primer 1 – Divide-and-conquer na nejasan problem

Situacija: Korisnik prijavljuje „ne radi mi portal firme", bez ijednog dodatnog detalja.

Dijagnostički proces:

1. ping 192.168.10.1 (gateway)          → uspeva
2. ping portal.firma.local              → propada (Destination host unreachable posle DNS greške)
3. nslookup portal.firma.local          → ne vraća adresu
4. ipconfig /all                        → DNS server: 8.8.8.8 (netačno, treba interni DC)

Objašnjenje: Prateći divide-and-conquer (Tema 1), prvi test (ping ka gateway-u) odmah potvrđuje da je osnovna IP povezanost ispravna — problem je „iznad" Layer 3 lokalne povezanosti. Drugi test izoluje problem na DNS rezoluciju (Tema 6), potvrđeno u Koraku 4 gde ipconfig /all otkriva netačan DNS server. Osnovni uzrok: korisnik je (verovatno slučajno, kroz neki alat ili ručno) promenio DNS server na javni umesto internog Domain Controller-a (Modul 17).

Primer 2 – Bottom-up na potpuni prekid veze

Situacija: Novi radna stanica, tek povezana na mrežu, nema nikakvu mrežnu aktivnost.

Dijagnostički proces:

1. Provera Link LED-a na mrežnoj kartici        → ne svetli
2. Provera kabla (fizička inspekcija)            → kabl vizuelno ispravan, čvrsto priključen
3. Provera drugog kabla (zamena)                 → Link LED sada svetli
4. ipconfig /all                                 → automatski dobija ispravnu DHCP adresu

Objašnjenje: Bottom-up pristup (Tema 1) je ovde ispravan izbor jer je informacija minimalna („ne radi ništa") — počinje se od najosnovnijeg fizičkog sloja (Tema 2). Link LED koji ne svetli odmah ukazuje na fizički problem, bez potrebe da se uopšte proveravaju IP konfiguracija ili viši slojevi. Zamena kabla (unutrašnje oštećenje, nevidljivo spolja) rešava problem — potvrđeno automatskim, uspešnim DHCP procesom odmah nakon fizičkog popravka.

Primer 3 – VLAN dodela nakon zamene opreme

Situacija: Nakon zamene starog sviča novim, zaposleni u Odeljenju Prodaje ne mogu da pristupe deljenom serveru koji im je ranije bio dostupan.

Dijagnostički proces:

Novi-SW#show vlan brief
VLAN Name           Status    Ports
1    default        active    Fa0/1, Fa0/2, Fa0/3 ...
20   Prodaja         active

Objašnjenje: show vlan brief (Tema 7) otkriva da su svi portovi zaposlenih Prodaje ostali u podrazumevanom VLAN-u 1, dok je server (i ostatak firme) na VLAN-u 20 — administrator koji je zamenio opremu nije preneo postojeću dodelu portova sa starog na novi svič. Rešenje: switchport access vlan 20 na svim relevantnim portovima, praćeno proverom da trunk port ka ostatku mreže dozvoljava VLAN 20 (show interfaces trunk).

Primer 4 – Duplex mismatch nakon delimičnog ručnog podešavanja

Situacija: Korisnici prijavljuju da je transfer velikih fajlova ka jednom konkretnom serveru „nepodnošljivo spor", iako je veza tehnički aktivna.

Dijagnostički proces:

SW1#show interfaces gigabitEthernet 0/5
GigabitEthernet0/5 is up, line protocol is up
  Full-duplex, 1000Mb/s
  ...
  1847 input errors, 1203 CRC, 644 late collision

Objašnjenje: Interfejs prikazuje up/up (fizička veza postoji, Tema 2), ali veliki broj CRC i late collision grešaka (Tema 3) je jasan znak duplex mismatch-a — SW1 port je podešen na Full-duplex, dok server na drugom kraju (proverom na samom serveru) koristi half-duplex usled starije mrežne kartice sa problematičnom auto-negotiation implementacijom. Rešenje: eksplicitno podesiti oba kraja na identičan duplex (preporučeno: oba na auto, ili oba ručno na full ako auto ne funkcioniše ispravno).

Primer 5 – ACL redosled blokira novo pravilo

Situacija: Administrator dodaje novo ACL pravilo da dozvoli pristup novom internom serveru, ali pristup i dalje ne radi.

Dijagnostički proces:

R1#show access-lists 110
Extended IP access list 110
    10 deny ip 192.168.20.0 0.0.0.255 any (312 matches)
    20 permit ip any host 192.168.30.100 (0 matches)
    30 permit ip any any (89 matches)

Objašnjenje: Novo dodato pravilo (linija 20, dozvoljava pristup ka 192.168.30.100) ima 0 pogodaka (Tema 9) — saobraćaj sa mreže 192.168.20.0/24 nikad ne stiže do njega jer ga ranije, opštije pravilo (linija 10) već odbija sa 312 pogodaka. Rešenje: preurediti redosled tako da specifično permit pravilo bude pre opšteg deny pravila koje bi ga inače presrelo, ili prepraviti deny pravilo da eksplicitno isključi izuzetak.

Primer 6 – Duple IP adrese uzrokuju isprekidan problem

Situacija: Dva korisnika u istoj kancelariji prijavljuju da im veza „radi pa ne radi" tokom cele nedelje, bez ikakvog jasnog obrasca.

Dijagnostički proces:

(Korisnik A, u različitim trenucima)
C:\>arp -a
  192.168.1.1    aa-bb-cc-11-22-33   dynamic

(par minuta kasnije)
C:\>arp -a
  192.168.1.1    aa-bb-cc-44-55-66   dynamic

Objašnjenje: Isti IP adresa (192.168.1.1) se pojavljuje sa dve različite MAC adrese u različitim trenucima (Tema 15) — definitivan znak konflikta IP adresa. Daljom istragom se otkriva da je 192.168.1.1 slučajno statički dodeljena novom mrežnom uređaju, dok je ta ista adresa i dalje unutar aktivnog DHCP opsega bez odgovarajuće excluded-address (Modul 13). Rešenje: promeniti statičku adresu novog uređaja van DHCP opsega, i dodati excluded-address da se ubuduće spreči slična greška.

Poslovni scenario – Rešavanje višestrukog incidenta u maloj firmi

Kontekst: Ponedeljak ujutru, nakon planiranog vikend održavanja mrežne opreme u firmi „Astrion Logistika", IT tim dobija tri odvojene prijave odjednom: (1) štampač u računovodstvu ne radi, (2) jedan zaposleni ne može da pristupi internetu, (3) veb portal firme je nedostupan spolja (za klijente).

Sistematska obrada tri odvojena incidenta:

Zajednički obrazac i preventivna mera: Sva tri incidenta imaju zajednički koren — planirano održavanje (restart opreme) je otkrilo tri odvojena mesta gde konfiguracija nije bila trajno sačuvana ili gde je oslanjanje na DHCP bez rezervacije bilo neprikladno. Dokumentacija incidenta (Tema 17) beleži ne samo tri pojedinačna rešenja, već i sistemsku preventivnu meru: standardna procedura pre bilo kog planiranog restarta ubuduće uključuje eksplicitnu proveru da je running-config sačuvan na svim uređajima, i reviziju svih kritičnih uređaja (štampači, serveri) da koriste statičke adrese ili DHCP rezervacije, ne običnu dinamičku dodelu.