Zadaci za samostalan rad – Modul 20 – 30 realnih scenarija sa posla
Rešenja se nalaze u
/resenja/modul-20/05-zadaci-resenja.md— pokušajte da rešite scenarije samostalno pre nego što pogledate rešenja. Za svaki scenario odgovorite: (a) koji dijagnostički pristup (bottom-up/top-down/divide-and-conquer) biste izabrali i zašto, (b) koji je najverovatniji uzrok, (c) koju konkretnu komandu/korak biste prvi preduzeli.
Metodologija i fizički sloj (Scenariji 1-4)
Scenario 1. Korisnik zove i kaže „internet mi ne radi", bez ijednog dodatnog detalja. Kolega pored njega, na istom svič-u, radi normalno.
Scenario 2. Novi radni sto je opremljen, kabl je povučen kroz zid, ali računar priključen na njega ne pokazuje nikakvu mrežnu aktivnost — Link LED na mrežnoj kartici ne svetli.
Scenario 3. Nakon čišćenja servera i restrukturiranja kablova u serverskom ormanu, jedan server iznenada nije dostupan, iako je pre čišćenja radio besprekorno.
Scenario 4. Prenos velikih fajlova ka jednom konkretnom serveru je „nepodnošljivo spor" (nekoliko KB/s umesto očekivanih MB/s), iako veza tehnički postoji i status svih interfejsa prikazuje „up".
IP konfiguracija i DHCP (Scenariji 5-8)
Scenario 5. Korisnik može da pristupi svim štampačima i deljenim folderima u kancelariji, ali ne i internetu ili resursima u drugoj poslovnici.
Scenario 6. Deset korisnika u jednoj kancelariji istovremeno prijavljuje da nemaju IP adresu (svi pokazuju 169.254.x.x).
Scenario 7. Klijent na udaljenoj poslovnici (povezanoj preko WAN linka ka centrali gde se nalazi jedini DHCP server) ne dobija nikakvu IP adresu, dok klijenti u centrali dobijaju adrese bez problema.
Scenario 8. Novi laptop je ručno (statički) konfigurisan kopiranjem podataka sa koleginog laptopa, uz izmenu samo poslednje cifre IP adrese. Laptop nema pristup internetu, ali može da pristupi lokalnim resursima.
DNS (Scenariji 9-11)
Scenario 9. ping 8.8.8.8 uspeva, ali ping google.com ne uspeva na istom uređaju.
Scenario 10. Korisnik prijavljuje da interni portal firme radi sporo — traje nekoliko sekundi da se stranica uopšte počne učitavati, iako sam sadržaj stranice nije veliki.
Scenario 11. Nakon što je administrator promenio IP adresu internog servera juče, danas polovina zaposlenih i dalje ne može da mu pristupi preko starog imena, dok druga polovina može.
VLAN, trunk i STP (Scenariji 12-14)
Scenario 12. Nakon zamene sviča u kancelariji, zaposleni u jednom odeljenju ne mogu da pristupe deljenom resursu koji su ranije koristili, iako je fizička veza (Link LED) u redu.
Scenario 13. Saobraćaj jednog konkretnog VLAN-a ne prolazi između dva sviča povezana trunk vezom, dok saobraćaj svih ostalih VLAN-ova prolazi normalno.
Scenario 14. Jedan svič port koji bi trebalo da bude aktivan (deo redundantne veze) prikazuje status „blocking" u show spanning-tree, i korisnici povezani na taj put prijavljuju da „ne rade".
Rutiranje, ACL i NAT (Scenariji 15-19)
Scenario 15. Nova podmreža je dodata u firmu prošle nedelje; korisnici na toj podmreži mogu da komuniciraju međusobno, ali ne i sa ostatkom firme.
Scenario 16. Administrator je juče dodao novo ACL pravilo da dozvoli pristup novom serveru, ali korisnici i dalje prijavljuju da im je pristup odbijen.
Scenario 17. Spoljni klijenti (sa interneta) ne mogu da pristupe javnom veb sajtu firme, iako interni korisnici mogu normalno da mu pristupe preko interne adrese.
Scenario 18. Nakon migracije internog servera na novu IP adresu, spoljni pristup preko static NAT-a je prestao da radi, iako interni pristup radi normalno.
Scenario 19. Firma je dodala treći ISP link kao rezervu (backup), ali saobraćaj i dalje uvek ide preko primarnog linka čak i kada je primarni link degradiran (spor, ali ne potpuno mrtav).
Wi-Fi (Scenariji 20-22)
Scenario 20. Zaposleni u konferencijskoj sali prijavljuje da mu se Wi-Fi veza povremeno prekida tačno tokom pauze za ručak, svaki dan u isto vreme.
Scenario 21. Novi zaposleni ne može da se poveže na kancelarijski Wi-Fi uopšte — uređaj vidi mrežu na listi, ali povezivanje neprestano ne uspeva.
Scenario 22. Korisnik u velikoj otvorenoj kancelariji prijavljuje da mu je Wi-Fi „spor" samo kada je u konferencijskoj sali na drugom kraju sprata, iako je signal (RSSI) prema njegovom telefonu prikazan kao „dobar".
Internet, serveri i štampači (Scenariji 23-26)
Scenario 23. Cela kancelarija (svi zaposleni) istovremeno gubi pristup internetu u isto vreme, bez ikakve prethodne izmene na internoj mreži.
Scenario 24. Korisnici prijavljuju da interna aplikacija „ne radi"; mrežni tim želi da brzo utvrdi da li je problem mrežni ili je u samoj aplikaciji/serveru.
Scenario 25. Mrežni štampač koji je juče radio normalno danas se ne pojavljuje kao dostupan nijednom klijentu u kancelariji, iako je štampač fizički uključen i pokazuje da je spreman na sopstvenom ekranu.
Scenario 26. Nakon planiranog restarta cele mrežne infrastrukture preko vikenda, u ponedeljak ujutru tri različita, naizgled nepovezana problema se prijavljuju istovremeno.
Duple adrese i kvalitet mreže (Scenariji 27-29)
Scenario 27. Dva korisnika u istoj kancelariji prijavljuju da im veza „radi pa ne radi", potpuno nepredvidivo, tokom cele nedelje.
Scenario 28. Firma koja koristi VoIP telefoniju preko WAN veze sa merenom propusnošću od 80% iskorišćenja (dovoljno slobodnog kapaciteta) i dalje prijavljuje isprekidan, loš kvalitet poziva.
Scenario 29. Prenos velikog fajla preko interneta radi normalno (bez ijedne primetne greške), ali video pozivi preko iste veze povremeno „zamrznu" sliku na par sekundi.
Dokumentovanje (Scenario 30)
Scenario 30. Tim je upravo završio rešavanje incidenta koji je trajao tri sata i pogodio pola kancelarije. Menadžment traži da se napravi izveštaj o incidentu pre kraja radnog dana.
📖 Prikaži rešenje
Rešenja zadataka za samostalan rad – Modul 20 – 30 realnih scenarija sa posla
Format odgovora za svaki scenario: (a) pristup, (b) najverovatniji uzrok, (c) prvi konkretan korak.
Metodologija i fizički sloj
Scenario 1. (a) Divide-and-conquer — kolega na istom svič-u radi, pa se problem verovatno može brzo suziti poređenjem njihove dve konfiguracije. (b) Klijentska konfiguracija (IP/DHCP/kabl) specifična za tog korisnika. (c) ipconfig /all na pogođenom računaru, uporediti sa kolegom.
Scenario 2. (a) Bottom-up — nema nikakve mrežne aktivnosti, minimalna informacija. (b) Neispravan kabl, loš konektor, ili port na svič-u koji nije aktivan. (c) Provera Link LED-a na mrežnoj kartici i na svič portu.
Scenario 3. (a) Bottom-up — radilo je pre fizičke intervencije. (b) Kabl je slučajno izvučen ili priključen na pogrešan port tokom čišćenja/restrukturiranja. (c) Fizička provera da je kabl priključen na ispravan port, provera Link LED-a.
Scenario 4. (a) Divide-and-conquer/bottom-up — veza „postoji" ali je spora, sumnja na Layer 1-2. (b) Duplex mismatch. (c) show interfaces na oba kraja veze, provera CRC/late collision brojača i duplex podešavanja.
IP konfiguracija i DHCP
Scenario 5. (a) Divide-and-conquer — lokalno radi, van mreže ne radi. (b) Pogrešan ili nedostajući default gateway. (c) ipconfig /all, proveriti da li je gateway u istoj podmreži kao IP adresa uređaja.
Scenario 6. (a) Top-down/opšti problem — više korisnika odjednom. (b) DHCP server je nedostupan ili je nedavno restartovan/pao. (c) Provera statusa DHCP servera (Cisco show ip dhcp binding ili Windows Server DHCP konzola).
Scenario 7. (a) Divide-and-conquer — izolovano na udaljenu mrežu specifično. (b) ip helper-address (DHCP relay) nedostaje na ruteru udaljene poslovnice, ili DHCP server nema pool definisan za tu mrežu. (c) Provera ip helper-address konfiguracije na udaljenom ruteru i postojanja odgovarajućeg ip dhcp pool na serveru.
Scenario 8. (a) Divide-and-conquer — lokalno radi, internet ne radi. (b) Gateway adresa je greškom ostala ista kao na koleginom laptopu, a možda ne odgovara stvarnoj mreži (ili je IP adresa duplikat, Scenario 27 tip problema). (c) ipconfig /all, provera da gateway odgovara stvarnoj mreži i da IP adresa nije duplikat (arp -a).
DNS
Scenario 9. (a) Divide-and-conquer, potvrđeno IP povezanošću. (b) DNS problem — pogrešan DNS server ili DNS server nedostupan. (c) nslookup google.com, proveriti koji DNS server odgovara (ili ne odgovara).
Scenario 10. (a) Top-down (mreža uglavnom radi, specifičan simptom). (b) Spor DNS odgovor (preopterećen ili udaljen DNS server) pre same HTTP konekcije. (c) dig portal.firma.local i provera „Query time" polja.
Scenario 11. (a) Divide-and-conquer po grupi korisnika. (b) DNS TTL — polovina korisnika i dalje ima keširanu staru IP adresu (visok TTL), dok je druga polovina već osvežila keš. (c) ipconfig /flushdns na pogođenim uređajima; provera TTL vrednosti DNS zapisa.
VLAN, trunk i STP
Scenario 12. (a) Bottom-up (fizička veza je potvrđeno u redu, sumnja ide na Layer 2). (b) Portovi nisu preneti u ispravan VLAN prilikom zamene sviča. (c) show vlan brief na novom svič-u.
Scenario 13. (a) Divide-and-conquer — samo jedan VLAN pogođen. (b) Taj VLAN nije uključen u switchport trunk allowed vlan listu na trunk vezi. (c) show interfaces trunk na oba kraja trunk veze.
Scenario 14. (a) Provera dokumentovane topologije/STP uloge (Tema 7). (b) Ovo je očekivano, ispravno STP ponašanje (redundantan link u blocking stanju da spreči petlju), ne kvar — problem korisnika je verovatno negde drugde. (c) show spanning-tree da se potvrdi da je blocking namerno/ispravno, zatim tražiti stvaran uzrok problema korisnika na aktivnom putu.
Rutiranje, ACL i NAT
Scenario 15. (a) Divide-and-conquer — lokalno radi (unutar podmreže), van ne radi. (b) Nedostaje statička ruta (ili OSPF network iskaz) ka novoj podmreži na susednim ruterima. (c) show ip route na susednim ruterima da se proveri da li ruta postoji.
Scenario 16. (a) Top-down/specifičan problem sa poznatom, nedavnom izmenom. (b) Redosled ACL pravila — opštije deny pravilo presreće saobraćaj pre novog permit pravila. (c) show access-lists, provera brojača pogodaka na novom pravilu (verovatno 0).
Scenario 17. (a) Divide-and-conquer — interno radi, spolja ne radi. (b) Static NAT mapiranje nedostaje, netačno je, ili ip nat outside oznaka nedostaje na graničnom interfejsu. (c) show ip nat translations da se proveri da li static prevod uopšte postoji.
Scenario 18. (a) Top-down/specifičan problem sa poznatom, nedavnom izmenom. (b) Static NAT mapiranje i dalje pokazuje na staru internu IP adresu servera. (c) show ip nat translations, uporediti internu adresu u mapiranju sa stvarnom, trenutnom adresom servera.
Scenario 19. (a) Provera routing/failover konfiguracije. (b) Nedostaje mehanizam za automatski failover (npr. IP SLA sa tracking-om, ili floating static route sa odgovarajućom administrativnom udaljenošću) koji bi prebacio saobraćaj na backup link kada je primarni degradiran, ne samo kada je potpuno mrtav. (c) Provera konfiguracije rute/administrativne udaljenosti i da li postoji mehanizam za detekciju degradacije (ne samo potpunog prekida) primarnog linka.
Wi-Fi
Scenario 20. (a) Sistematska Wi-Fi dijagnostika (Modul 14/20 Tema 11) — ponovljiv obrazac po vremenu. (b) Ne-Wi-Fi izvor smetnji (mikrotalasna pećnica) u blizini, aktivna tačno u vreme pauze za ručak. (c) Provera fizičke blizine access point-a i mikrotalasne pećnice/kuhinje.
Scenario 21. (a) Sistematska Wi-Fi dijagnostika — problem je pre DHCP faze. (b) Pogrešna lozinka ili nepoklapanje bezbednosnog standarda (WPA2/WPA3). (c) Provera unete lozinke i bezbednosnog moda na uređaju naspram access point-a.
Scenario 22. (a) Sistematska Wi-Fi dijagnostika — signal je dobar, sumnja ide na kapacitet/smetnje. (b) Konferencijska sala ima mnogo istovremenih korisnika deleći isti access point (problem kapaciteta, ne signala) ili ko-kanalna interferencija sa susednim access point-ima. (c) Provera broja istovremeno povezanih korisnika na tom access point-u i kanala koje koristi.
Internet, serveri i štampači
Scenario 23. (a) Top-down/opšti problem — svi odjednom. (b) Problem na strani ISP-a ili graničnog rutera/modema, ne interne mreže. (c) Provera status LED indikatora na modemu/graničnom ruteru (veza ka ISP-u).
Scenario 24. (a) Divide-and-conquer, sistematska provera mreža naspram aplikacija. (b) Nepoznato unapred — upravo to je svrha testa. (c) ping ka IP adresi servera, zatim provera konkretnog porta lokalno pa spolja.
Scenario 25. (a) Bottom-up/specifičan uređaj. (b) Štampač je koristio DHCP bez rezervacije i dobio novu IP adresu (npr. nakon restarta), dok su klijenti podešeni na staru. (c) Provera trenutne IP adrese štampača (na njegovom ekranu) naspram adrese konfigurisane na klijentima.
Scenario 26. (a) Obrada svaka tri problema odvojeno, svaki sopstvenom odgovarajućom metodologijom, uz svest da svi dele zajednički okidač (restart). (b) Verovatno kombinacija: nesačuvane konfiguracije pre restarta, i/ili uređaji koji koriste DHCP bez rezervacije umesto statičkih adresa. (c) Za svaki problem posebno, sistematska dijagnostika (Tema 1); nakon rešavanja, tražiti zajednički uzrok/preventivnu meru.
Duple adrese i kvalitet mreže
Scenario 27. (a) Sumnja na konflikt IP adresa zbog isprekidanog obrasca. (b) Dva uređaja dele istu IP adresu. (c) arp -a na oba uređaja/okolnim uređajima u različitim vremenskim trenucima, provera da li se MAC adresa za istu IP adresu menja.
Scenario 28. (a) Provera kvaliteta mreže odvojeno od kapaciteta/propusnosti. (b) Visok jitter (varijacija latencije) ili packet loss, ne nedostatak propusnosti — VoIP je osetljiv na ta dva faktora, ne na sirovi protok. (c) Merenje jitter-a i packet loss-a (npr. Wireshark analiza VoIP saobraćaja, Modul 19), ne samo iskorišćenost propusnosti.
Scenario 29. (a) Razdvajanje protoka od latencije/jitter-a kao odvojenih mera. (b) Prenos fajla je manje osetljiv na jitter/kratkotrajni packet loss (TCP retransmituje neprimetno uz dovoljno propusnosti), dok video poziv (realnovremenski, osetljiviji na kašnjenje) odmah pokazuje efekat istog, kratkotrajnog problema. (c) Wireshark analiza (Modul 19) tokom video poziva, provera retransmisija/jitter-a specifično u tom vremenskom prozoru.
Dokumentovanje
Scenario 30. Izveštaj treba da sadrži svih šest elemenata iz Teme 17: vremenski okvir (kada je počelo, prijavljeno, rešeno), simptomi (tačno šta je prijavljeno, koliko korisnika), dijagnostički proces (koji koraci/alati su korišćeni, uključujući „ćorsokake"), osnovni uzrok (konkretan tehnički uzrok, ne samo simptom), preduzete mere (tačno šta je promenjeno), i preventivne mere (šta će sprečiti ponavljanje) — sve napisano dok su detalji još uvek sveži, odmah nakon rešavanja, ne odloženo za kasnije kada se detalji zaborave.