Teorija – Modul 23 – Nadzor i dokumentovanje mreže

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 – Zašto dokumentacija i nadzor

1. Jednostavno objašnjenje

Dokumentacija govori kako mreža izgleda, a nadzor govori kako mreža radi upravo sada. Bez dokumentacije svaki kvar počinje pitanjem „gde je šta povezano?", a bez nadzora za problem saznajete tek kada korisnici počnu da zovu.

2. Stručno objašnjenje

Dokumentacija mreže je skup ažurnih zapisa o opremi, vezama, adresama, VLAN-ovima, konfiguracijama i procedurama. Nadzor (monitoring) je kontinuirano, automatsko prikupljanje podataka o stanju mreže — dostupnosti uređaja, iskorišćenosti linkova, greškama i događajima — uz upozorenja kada vrednosti izađu iz očekivanih granica. Zajedno omogućavaju: brže rešavanje problema (kraće MTTR — Mean Time To Repair), proaktivno otkrivanje problema pre nego što pogode korisnike, planiranje kapaciteta, ispunjavanje ugovornih obaveza (SLA) i bezbednosnih zahteva (revizije, standardi poput ISO 27001), kao i prenos znanja kada administrator ode iz firme.

3. Primer iz svakodnevnog života

Automobil ima servisnu knjižicu (dokumentacija — šta je menjano i kada) i instrument tablu (nadzor — temperatura motora, pritisak ulja, lampica za gorivo). Bez knjižice mehaničar nagađa, a bez instrument table motor pregreje pre nego što primetite.

4. Primer iz poslovnog IT okruženja

Administrator firme sa 60 zaposlenih odlazi, a novi administrator zatiče mrežu bez ijednog dijagrama. Prvi kvar sviča na spratu traje četiri sata jer niko ne zna koji port na glavnom sviču vodi do tog sprata ni koja je lozinka uređaja. Nakon toga firma uvodi obaveznu dokumentaciju i monitoring sistem.

5. Praktična vežba / napomena

Uzmite svoju kućnu mrežu i pokušajte napamet da navedete: model rutera, njegovu LAN adresu, opseg DHCP adresa, lozinku za administraciju i kada je poslednji put ažuriran firmware. Svaka stavka koju ne znate je „rupa" u dokumentaciji.

6. Najčešće greške

• Dokumentacija napravljena jednom i nikada ažurirana — zastarela dokumentacija može biti opasnija od nepostojeće.
• Monitoring koji šalje upozorenja koja niko ne čita.
• Čuvanje dokumentacije samo u glavi jedne osobe.

7. Pitanje za proveru znanja

P: Koja je osnovna razlika između dokumentacije i nadzora mreže? O: Dokumentacija opisuje kako je mreža izgrađena i podešena (statično stanje), a nadzor kontinuirano prati kako mreža radi u realnom vremenu (dinamičko stanje) i upozorava na probleme.

Tema 2 – Inventar opreme

1. Jednostavno objašnjenje

Inventar je spisak svih mrežnih uređaja sa ključnim podacima: šta je uređaj, gde se nalazi, koji je serijski broj, koja verzija softvera radi na njemu i do kada važi garancija.

2. Stručno objašnjenje

Evidencija opreme (asset inventory) za svaki uređaj beleži: naziv (hostname), tip i model, serijski broj, verziju operativnog sistema (IOS/firmware), upravljačku IP adresu, lokaciju (zgrada/sprat/orman/pozicija u rack-u), datum nabavke, status garancije i ugovora o podršci, datum isteka podrške proizvođača (End of Life / End of Support) i odgovornu osobu. Podaci se prikupljaju komandama poput show version (model, serijski broj u polju Processor board ID, verzija IOS-a, uptime) i show inventory (moduli i serijski brojevi komponenti), ili automatski preko SNMP-a (tablica ENTITY-MIB). U većim sistemima inventar se vodi u CMDB-u (Configuration Management Database) ili alatima poput NetBox-a.

3. Primer iz svakodnevnog života

Popis stvari za osiguranje stana: TV, laptop, frižider — sa modelom, serijskim brojem i računom. Kada nešto nestane ili se pokvari, sve potrebne informacije su na jednom mestu.

4. Primer iz poslovnog IT okruženja

Proizvođač objavljuje kritičnu bezbednosnu ranjivost u određenoj verziji IOS-a. Administrator sa ažurnim inventarom za pet minuta zna da su pogođena tačno tri uređaja i gde se nalaze; administrator bez inventara mora da se loguje na svaki uređaj redom.

5. Praktična vežba / napomena

Na bilo kom Cisco uređaju u Packet Traceru izvršite show version i pronađite: model, verziju IOS-a, uptime i serijski broj. Ta četiri podatka su minimum za evidenciju opreme.

6. Najčešće greške

• Inventar bez verzije softvera — ne može se proceniti izloženost ranjivostima.
• Nepraćenje datuma isteka podrške — oprema koja više ne dobija zakrpe ostaje u produkciji.
• Zaboravljanje „nevidljive" opreme: access point-ova, UPS uređaja, medijskih konvertora.

7. Pitanje za proveru znanja

P: Zašto je u inventaru važno beležiti verziju operativnog sistema uređaja? O: Da bi se brzo utvrdilo koji su uređaji pogođeni objavljenom ranjivošću ili greškom, i da bi se planirala ažuriranja.

Tema 3 – Mrežni dijagrami: fizički i logički

1. Jednostavno objašnjenje

Fizički dijagram pokazuje gde su uređaji i kojim kablovima su povezani. Logički dijagram pokazuje kako podaci teku — mreže, VLAN-ove, adrese i rutiranje.

2. Stručno objašnjenje

Fizički dijagram (Layer 1) prikazuje stvarne uređaje, njihove lokacije (prostorije, ormane), tačne portove na oba kraja svake veze, tip kabla/medija (Cat6, OM3 optika) i veze ka provajderu. Logički dijagram (Layer 2/3) prikazuje IP mreže i prefikse, VLAN-ove, podrazumevane gateway-e, protokole rutiranja i oblasti (npr. OSPF area), firewall zone, VPN tunele. Dobra praksa: dijagram ima legendu, datum i verziju, autora, i ne prikazuje sve na jednoj slici — veće mreže imaju pregledni dijagram plus detaljne dijagrame po lokacijama. Alati: draw.io (diagrams.net), Microsoft Visio, Lucidchart, a za „dijagram kao kod" Mermaid ili Graphviz.

3. Primer iz svakodnevnog života

Fizički dijagram je kao građevinski plan instalacija u stanu (gde prolaze cevi i kablovi kroz zidove). Logički dijagram je kao mapa gradskog prevoza — ne vidite gde tačno prolaze šine, ali znate koja linija vodi do koje stanice.

4. Primer iz poslovnog IT okruženja

Pri kvaru jednog sviča tehničar na terenu koristi fizički dijagram da pronađe orman i port, a inženjer u centrali koristi logički dijagram da proceni koje su VLAN mreže i servisi pogođeni.

5. Praktična vežba / napomena

Nacrtajte na papiru ili u draw.io kućnu mrežu u dve verzije: fizičku (ruter, kablovi, Wi-Fi uređaji, sobe) i logičku (mreža 192.168.x.0/24, gateway, DHCP opseg, DNS server).

6. Najčešće greške

• Mešanje fizičkog i logičkog prikaza na jednom dijagramu tako da nijedan nije čitljiv.
• Dijagram bez datuma i verzije — ne zna se da li je aktuelan.
• Izostavljanje oznaka portova na vezama.

7. Pitanje za proveru znanja

P: Koji dijagram koristite da biste utvrdili na koji port sviča je povezan server, a koji da biste videli u kojoj je IP mreži? O: Fizički dijagram za port i kabl; logički dijagram za IP mrežu i VLAN.

Tema 4 – IP adresni plan

1. Jednostavno objašnjenje

IP adresni plan je tabela koja kaže koja mreža služi čemu i koja adresa pripada kom uređaju, tako da se adrese nikada ne dupliraju i da je lako naći slobodnu.

2. Stručno objašnjenje

IP adresni plan (u širem smislu IPAM — IP Address Management) za svaku mrežu beleži: prefiks i masku, namenu, VLAN ID, gateway, DHCP opseg (i izuzete adrese), statičke adrese sa nazivom uređaja, DNS servere i rezervu za rast. Dobra praksa je dosledna struktura unutar svake mreže, npr. .1 gateway, .2–.9 mrežna oprema, .10–.49 serveri i štampači sa statičkom adresom, .50–.250 DHCP. Plan se oslanja na VLSM iz Modula 5 i treba da omogući sumarizaciju ruta po lokacijama. Za veće mreže koriste se IPAM alati (NetBox, phpIPAM, Windows Server IPAM) koji otkrivaju zauzete adrese i sprečavaju konflikte.

3. Primer iz svakodnevnog života

Raspored sedenja u učionici — svako mesto ima broj, zna se koja su mesta slobodna, i dva učenika ne mogu dobiti isto mesto.

4. Primer iz poslovnog IT okruženja

Novi mrežni štampač dobija „slučajno izabranu" statičku adresu koja je već u DHCP opsegu. Sledećeg jutra jedan računar dobija istu adresu i nastaje konflikt (Modul 20). Sa adresnim planom i pravilom „statičke adrese samo u opsegu .10–.49" to se ne bi desilo.

5. Praktična vežba / napomena

Otvorite šablon IP adresni plan i popunite ga za laboratoriju iz Modula 13.

6. Najčešće greške

• Statičke adrese dodeljene unutar DHCP opsega.
• Plan bez rezerve — nova mreža ne može da se doda bez prenumeracije.
• Adresni plan u jednoj tabeli, a stvarno stanje drugačije — plan se ne ažurira pri izmenama.

7. Pitanje za proveru znanja

P: Zašto se u svakoj mreži definiše poseban opseg za statičke adrese izvan DHCP opsega? O: Da DHCP server nikada ne bi dodelio adresu koja je već statički dodeljena nekom uređaju, čime se sprečavaju konflikti adresa.

Tema 5 – VLAN tabela

1. Jednostavno objašnjenje

VLAN tabela je spisak svih VLAN-ova sa brojem, nazivom, namenom i mrežom — da svi administratori koriste iste brojeve za iste namene.

2. Stručno objašnjenje

VLAN dokumentacija beleži: VLAN ID, naziv (identičan na svim svičevima), namenu, pridruženu IP mrežu i gateway, na kojim svičevima i trunk vezama postoji (allowed VLAN lista), native VLAN na trunk-ovima, i posebne napomene (voice VLAN, management VLAN, guest VLAN, VLAN-ovi koji ne smeju da se rutiraju). Dosledna šema brojeva olakšava rad, npr. 10–99 korisnici po odeljenjima, 100–199 serveri, 900+ upravljanje i infrastruktura. Uz tabelu se vodi i matrica „svič × VLAN" koja pokazuje gde koji VLAN postoji — ključna za dijagnostiku problema iz Modula 9 i Modula 20 (VLAN nije dozvoljen na trunk-u).

3. Primer iz svakodnevnog života

Boje fascikli u kancelariji: plava je uvek za račune, crvena za ugovore. Ako svaki zaposleni koristi svoje boje, niko ne može da nađe dokument.

4. Primer iz poslovnog IT okruženja

Na jednom sviču VLAN 20 je „Racunovodstvo", a na drugom „Magacin". Tehničar povezuje računar magacina na port u VLAN-u 20 na prvom sviču i računar dobija adresu iz mreže računovodstva — bezbednosni propust nastao zbog nedosledne dokumentacije.

5. Praktična vežba / napomena

Otvorite šablon VLAN dokumentacija i popunite ga za laboratoriju iz Modula 9 (VLAN 10, 20, 30, 99).

6. Najčešće greške

• Različiti nazivi istog VLAN-a na različitim svičevima.
• Nedokumentovan native VLAN — uzrok native VLAN mismatch problema.
• VLAN-ovi koji postoje na svičevima ali se više ne koriste („zaboravljeni" VLAN-ovi).

7. Pitanje za proveru znanja

P: Pored ID-ja i naziva, koja dva podatka o VLAN-u su najvažnija za dijagnostiku problema sa trunk vezama? O: Na kojim svičevima i trunk vezama je VLAN dozvoljen (allowed lista) i koji je native VLAN na trunk vezama.

Tema 6 – Dokumentovanje portova (description, CDP, LLDP)

1. Jednostavno objašnjenje

Svaki port treba da „kaže" šta je na njega povezano. To se postiže opisom (description) na samom uređaju i tabelom portova, a protokoli CDP i LLDP pomažu da se automatski otkrije ko je sused.

2. Stručno objašnjenje

Evidencija portova za svaki port beleži: uređaj i port, povezani uređaj i njegov port, VLAN ili trunk, brzinu/duplex, patch panel poziciju i utičnicu (npr. „PP1-12 → soba 203, utičnica 2"). Na samom uređaju isti podatak se upisuje komandom description u interfejs režimu (vidljiv u show interfaces status na sviču i u show interfaces), jer je opis „dokumentacija koja putuje sa konfiguracijom".

CDP (Cisco Discovery Protocol) je Cisco-ov Layer 2 protokol koji periodično (podrazumevano svakih 60 s) oglašava naziv uređaja, model, port i IP adresu direktnim susedima; show cdp neighbors i show cdp neighbors detail prikazuju te podatke. LLDP (Link Layer Discovery Protocol, IEEE 802.1AB) je standardni ekvivalent koji podržavaju svi proizvođači (uključuje se sa lldp run, prikaz show lldp neighbors). Iz bezbednosnih razloga (Modul 16) CDP/LLDP se isključuju na portovima prema korisnicima i internetu (no cdp enable), jer otkrivaju modele i verzije softvera.

3. Primer iz svakodnevnog života

Etikete na kablovima iza TV-a: „TV", „risiver", „zvučnik levo". Bez njih, kada izvučete jedan kabl, nagađate koji je čiji.

4. Primer iz poslovnog IT okruženja

Nasleđeni svič ima 48 portova bez ikakvih opisa. Administrator komandom show cdp neighbors za minut otkriva sve susedne Cisco uređaje i na kojim su portovima, i odmah im dodeljuje opise poput description UPLINK-SW-SPRAT2-Gi0/1.

5. Praktična vežba / napomena

U bilo kojoj ranijoj Packet Tracer laboratoriji izvršite show cdp neighbors na ruteru i sviču i uporedite rezultat sa onim što vidite na topologiji.

6. Najčešće greške

• Opisi portova koji ne prate stvarno stanje posle premeštanja kablova.
• Ostavljen CDP/LLDP na portovima ka internetu ili gostima.
• Očekivanje da CDP vidi računare — CDP šalju samo uređaji koji ga podržavaju (Cisco oprema, IP telefoni).

7. Pitanje za proveru znanja

P: Koja je razlika između CDP-a i LLDP-a? O: CDP je vlasnički Cisco protokol, a LLDP je otvoren IEEE 802.1AB standard koji podržavaju uređaji različitih proizvođača; oba otkrivaju direktno povezane susede.

Tema 7 – Konvencije imenovanja uređaja

1. Jednostavno objašnjenje

Naziv uređaja treba da odmah kaže gde je uređaj i šta je, na primer BG-C-SW-02 umesto Switch ili Marko-svic.

2. Stručno objašnjenje

Konvencija imenovanja je dogovoreno pravilo za hostname-ove koje se dosledno primenjuje na sve uređaje. Tipična struktura: lokacija – zgrada/sprat – uloga – redni broj, npr. NS-HQ-R-01 (Novi Sad, centrala, ruter 1), BG-S2-SW-03 (Beograd, sprat 2, svič 3), NS-HQ-FW-01, NS-HQ-AP-12. Pravila: samo slova, brojevi i crtica (hostname pravila iz DNS-a), fiksna dužina segmenata, bez imena ljudi i bez podataka koji se menjaju (npr. IP adrese). Isti naziv se koristi u hostname-u, DNS zapisu, inventaru, dijagramu i monitoring sistemu, pa se podaci iz različitih izvora lako povezuju. Naziv se pojavljuje i u Syslog porukama i u promptu uređaja, što smanjuje rizik da se komanda izvrši na pogrešnom uređaju.

3. Primer iz svakodnevnog života

Oznake ulica i kućnih brojeva — svaka adresa jedinstveno određuje mesto. Opis „kuća pored zelene ograde" radi dok neko ne ofarba ogradu.

4. Primer iz poslovnog IT okruženja

Administrator ima otvorene SSH sesije ka dva uređaja nazvana Router. Komanda reload je izvršena na pogrešnom — i centrala ostaje bez interneta. Uz nazive NS-HQ-R-01 i NS-LAB-R-01 greška bi bila očigledna.

5. Praktična vežba / napomena

Osmislite konvenciju imenovanja za firmu sa centralom u Nišu i poslovnicom u Kragujevcu, i napišite nazive za dva rutera, četiri sviča i tri access point-a.

6. Najčešće greške

• Nazivi po imenima ljudi ili temama (Zeus, Olimp) — ne govore ništa o ulozi i lokaciji.
• Nedosledna primena (deo uređaja po novoj, deo po staroj šemi).
• Upotreba razmaka ili specijalnih znakova koji ne važe u DNS nazivima.

7. Pitanje za proveru znanja

P: Zašto hostname uređaja ne treba da sadrži njegovu IP adresu? O: Zato što se adresa može promeniti, pa bi naziv postao netačan; naziv treba da sadrži samo trajne podatke (lokacija, uloga, redni broj).

Tema 8 – Backup konfiguracija

1. Jednostavno objašnjenje

Konfiguracija svakog uređaja se redovno kopira na drugo mesto, da bi se posle kvara ili greške uređaj brzo vratio u ispravno stanje.

2. Stručno objašnjenje

Backup konfiguracija čuva running-config (i po potrebi startup-config) svakog uređaja na centralnom serveru. Metode: ručno copy running-config tftp: (nešifrovano, samo u izolovanoj upravljačkoj mreži), bezbednije copy running-config scp: ili SFTP, automatski ugrađenom Cisco archive funkcijom (path, write-memory, time-period) ili alatima poput Oxidized, RANCID i Ansible-a (Modul 24). Dobra praksa:

• Automatski i redovno (npr. svake noći) i posle svake izmene.
• Verzionisanje — nazivi sa datumom (NS-HQ-R-01_2026-09-25.cfg) ili čuvanje u Git repozitorijumu, pa se razlike (diff) između verzija vide odmah.
• Pravilo 3-2-1 — tri kopije, na dva različita medija, jedna van lokacije.
• Zaštita — backup sadrži hash-eve lozinki, SNMP community stringove i ključeve, pa je poverljiv dokument.
• Test vraćanja — backup koji nikada nije vraćen nije proveren backup.

3. Primer iz svakodnevnog života

Fotografije sa telefona koje se automatski kopiraju na cloud i na eksterni disk — kada telefon padne u vodu, slike nisu izgubljene.

4. Primer iz poslovnog IT okruženja

Svič na spratu izgori. Novi svič istog modela stiže za dva sata; administrator učitava sinoćni backup konfiguracije i za deset minuta svi VLAN-ovi, opisi portova i port security rade kao pre kvara. Bez backup-a, rekonstrukcija bi trajala ceo dan.

5. Praktična vežba / napomena

U laboratoriji Modula 13 već ste koristili copy running-config tftp. Razmislite: gde bi se taj fajl čuvao u stvarnoj firmi i ko bi imao pristup?

6. Najčešće greške

• Backup samo „kad se setimo".
• Backup koji se čuva na istom uređaju ili u istoj prostoriji kao original.
• TFTP preko nepouzdane mreže — konfiguracija putuje nešifrovano.
• Nikada isproban postupak vraćanja konfiguracije.

7. Pitanje za proveru znanja

P: Zašto je korisno čuvati backup konfiguracija u Git repozitorijumu? O: Git čuva svaku verziju sa datumom i autorom, pa se jednostavno vidi tačna razlika između dve verzije konfiguracije i lako vraća prethodno stanje.

Tema 9 – SNMP u funkciji nadzora

1. Jednostavno objašnjenje

SNMP je način na koji monitoring server „pita" uređaje kako su — koliko dugo rade, koliko saobraćaja prolazi kroz portove, da li je neki port pao — a uređaji mogu i sami da jave kada se nešto važno desi.

2. Stručno objašnjenje

SNMP (osnove u Modulu 13) ima tri elementa: manager (NMS — monitoring server), agent (softver na uređaju) i MIB (Management Information Base — hijerarhijska baza objekata). Svaki objekat ima OID (Object Identifier), npr. 1.3.6.1.2.1.1.5.0 je sysName, 1.3.6.1.2.1.1.3.0 je sysUpTime, a tabela ifTable/ifXTable sadrži status i brojače interfejsa (ifOperStatus, ifInOctets, ifHCInOctets, ifInErrors).

Operacije: Get (jedna vrednost), GetNext/GetBulk (prolazak kroz tabele — alat snmpwalk), Set (izmena — u praksi se retko dozvoljava), Trap/Inform (agent sam šalje obaveštenje manageru na UDP port 162, npr. „link down"). Upiti idu na UDP port 161.

Verzije: v1 i v2c — autentifikacija samo preko community stringa koji putuje nešifrovano (v2c dodaje GetBulk i 64-bitne brojače); v3 — korisnici sa autentifikacijom (SHA) i šifrovanjem (AES), sa nivoima noAuthNoPriv, authNoPriv i authPriv. U produkciji se preporučuje SNMPv3 authPriv; ako se koristi v2c, obavezno: samo read-only community, nepredvidiv string (ne public), i ograničenje pristupa ACL-om samo na adresu monitoring servera.

3. Primer iz svakodnevnog života

Lekar na viziti (manager) proverava pacijente jednog po jednog i beleži temperaturu i pritisak (polling), a pacijent ima i dugme za hitno pozivanje sestre (trap) kada se nešto iznenada dogodi.

4. Primer iz poslovnog IT okruženja

Monitoring server na svakih 5 minuta čita ifHCInOctets sa uplink portova svih svičeva i crta grafikone saobraćaja, a kada uplink padne, svič odmah šalje linkDown trap i dežurni inženjer dobija upozorenje za nekoliko sekundi, a ne tek pri sledećem upitu.

5. Praktična vežba / napomena

Na Cisco uređaju SNMPv2c read-only pristup se uključuje komandom snmp-server community <string> ro, a SNMPv3 grupom i korisnikom (snmp-server group NADZOR v3 priv i snmp-server user nms NADZOR v3 auth sha <lozinka> priv aes 128 <lozinka>). U laboratoriji ovog modula koristićete v2c jer ga Packet Tracer podržava.

6. Najčešće greške

• Ostavljen podrazumevani community public, ili private sa RW pravima — napadač može da menja konfiguraciju.
• SNMP dostupan sa bilo koje adrese, bez ACL ograničenja.
• Korišćenje 32-bitnih brojača (ifInOctets) na brzim linkovima — brojač se „prelije" (wrap) za desetine sekundi na 1 Gb/s i grafikoni postaju netačni; koristiti ifHCInOctets.
• Zaboravljeno da trap ide na UDP 162 — firewall ga blokira.

7. Pitanje za proveru znanja

P: Koja je razlika između SNMP polling-a i SNMP trap-a? O: Kod polling-a manager periodično šalje upite agentu (UDP 161); trap je poruka koju agent sam šalje manageru (UDP 162) odmah kada se desi događaj.

Tema 10 – Syslog u funkciji nadzora

1. Jednostavno objašnjenje

Svaki uređaj beleži događaje („port je pao", „neko je promenio konfiguraciju"). Syslog šalje te poruke na jedan centralni server, gde se čuvaju, pretražuju i povezuju.

2. Stručno objašnjenje

Syslog poruka na Cisco uređaju ima format %FACILITY-SEVERITY-MNEMONIC: opis, npr. %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down. Nivoi ozbiljnosti (severity):

Komanda logging trap <nivo> šalje serveru poruke tog nivoa i svih ozbiljnijih (manjeg broja). Syslog koristi UDP port 514 (nepouzdano; za pouzdan i šifrovan prenos postoje TCP i TLS varijante). Centralizovani Syslog server (rsyslog, syslog-ng, Graylog, ELK/OpenSearch, Splunk) omogućava pretragu, korelaciju i zadržavanje logova, a logovi ostaju sačuvani i kada uređaj izgubi lokalni buffer ili se restartuje.

Vremenske oznake su ključne: service timestamps log datetime msec dodaje datum i vreme sa milisekundama, a svi uređaji moraju biti sinhronizovani preko NTP-a — bez toga je nemoguće utvrditi redosled događaja na više uređaja.

3. Primer iz svakodnevnog života

Brodski dnevnik u koji se upisuje svaki važan događaj sa tačnim vremenom. Ako svaki član posade vodi svoj dnevnik po svom satu, posle nezgode niko ne može da rekonstruiše šta se desilo prvo.

4. Primer iz poslovnog IT okruženja

Korisnici prijavljuju kratak prekid u 10:14. Na Syslog serveru administrator filtrira poruke iz tog minuta i vidi: 10:13:58 %SYS-5-CONFIG_I na ruteru (neko je menjao konfiguraciju), pa 10:14:02 %OSPF-5-ADJCHG ... to DOWN. Uzrok je pronađen za dva minuta — zahvaljujući centralizovanim logovima sa NTP-sinhronizovanim vremenom.

5. Praktična vežba / napomena

Setite se poruka koje ste videli u Packet Traceru posle no shutdown na interfejsu. Odredite nivo ozbiljnosti za %LINK-5-CHANGED i %LINEPROTO-5-UPDOWN.

6. Najčešće greške

• Uređaji bez NTP-a — vremena u logovima se ne poklapaju.
• logging trap debugging u produkciji — server zatrpan porukama.
• Previsok prag (npr. logging trap errors) — izgubljene važne poruke nivoa 4 i 5, poput promena konfiguracije.
• Logovi se čuvaju samo lokalno u buffer-u uređaja, koji se briše pri restartu.

7. Pitanje za proveru znanja

P: Ako je podešeno logging trap warnings, da li će server primiti poruku %LINEPROTO-5-UPDOWN? Zašto? O: Neće. warnings je nivo 4, pa se šalju samo poruke nivoa 0–4; poruka nivoa 5 (notifications) se ne šalje.

Tema 11 – Monitoring sistemi: Zabbix, PRTG, LibreNMS, Grafana

1. Jednostavno objašnjenje

Monitoring sistem je program koji stalno proverava sve uređaje, crta grafikone i šalje upozorenja. Postoji više takvih programa, a razlikuju se po ceni, složenosti i nameni.

2. Stručno objašnjenje

Monitoring sistem (NMS — Network Monitoring System) prikuplja podatke (SNMP polling i trap-ove, ICMP, provere portova i servisa, agente na serverima, Syslog, NetFlow), čuva ih kao vremenske serije, prikazuje ih na kontrolnim tablama (dashboard) i generiše upozorenja prema definisanim pravilima.

Arhitekturni izbor: agentless (SNMP, ICMP — bez instalacije na uređaju, standard za mrežnu opremu) naspram agent-based (softver na serveru, detaljniji podaci o OS-u i aplikacijama). Monitoring server mora biti u upravljačkoj mreži, sa sopstvenim nadzorom (ko nadgleda onog koji nadgleda?).

3. Primer iz svakodnevnog života

Pametni kućni sistem: senzori temperature i dima (kolektori), aplikacija sa grafikonima (dashboard) i poruka na telefon kada se detektuje dim (upozorenje).

4. Primer iz poslovnog IT okruženja

Firma sa 30 svičeva i 10 servera bira Zabbix za servere i mrežu, a za upravu pravi Grafana kontrolnu tablu sa dostupnošću ključnih servisa i iskorišćenošću internet veze.

5. Praktična vežba / napomena

Ovaj modul obrađuje monitoring sisteme na nivou koncepta. Dodatni izazov laboratorijske vežbe pokazuje SNMP i Syslog na Ubuntu Server VM-u iz Modula 18, što je temelj na koji se svaki od ovih sistema oslanja.

6. Najčešće greške

• Uvođenje monitoring sistema bez definisanja šta je „normalno" (bez baseline-a) i šta treba da izazove upozorenje.
• Monitoring server bez backup-a i bez sopstvenog nadzora.
• Očekivanje da Grafana sama prikuplja SNMP podatke — potreban je izvor podataka.

7. Pitanje za proveru znanja

P: Zašto se za mrežnu opremu pretežno koristi agentless nadzor? O: Zato što se na svičeve i rutere ne može (niti je poželjno) instalirati dodatni softver; oni već imaju ugrađene SNMP agente, Syslog i odgovaraju na ICMP.

Tema 12 – Dostupnost (availability) i SLA

1. Jednostavno objašnjenje

Dostupnost je procenat vremena u kome je servis radio. „99,9%" zvuči kao savršeno, ali znači skoro devet sati prekida godišnje.

2. Stručno objašnjenje

Dostupnost = (ukupno vreme − vreme nedostupnosti) / ukupno vreme × 100%. Dozvoljeno vreme nedostupnosti po nivoima („devetke"):

SLA (Service Level Agreement) je ugovor koji definiše garantovanu dostupnost, način merenja, vreme odziva na prijavu i penale. Povezani pokazatelji: MTBF (Mean Time Between Failures — prosečno vreme između kvarova) i MTTR (prosečno vreme popravke); dostupnost ≈ MTBF / (MTBF + MTTR). Dostupnost se meri ICMP proverama, proverama servisa (TCP port, HTTP odgovor) i praćenjem sysUpTime. Dostupnost serijski povezanih komponenti se množi: dve komponente od po 99,9% daju ≈ 99,8%, a redundansa (paralelne komponente) povećava ukupnu dostupnost.

3. Primer iz svakodnevnog života

Gradski prevoz koji „radi 99% vremena" ima više od tri i po dana godišnje bez ijednog autobusa — to bi svako primetio.

4. Primer iz poslovnog IT okruženja

Provajder garantuje 99,5% mesečne dostupnosti internet veze. Tokom meseca veza je bila nedostupna 5 sati. Dozvoljeno je 3,6 h, pa firma na osnovu izveštaja iz svog monitoring sistema traži umanjenje računa prema SLA-u.

5. Praktična vežba / napomena

Izračunajte dostupnost servera koji je u mesecu od 30 dana bio nedostupan 2 sata: (720 − 2) / 720 × 100% = 99,72%.

6. Najčešće greške

• Merenje samo „ping odgovara" — server može da odgovara na ping dok aplikacija ne radi.
• Ignorisanje planiranog održavanja u računanju (SLA mora da definiše da li se računa).
• Oslanjanje isključivo na izveštaj provajdera, bez sopstvenog merenja.

7. Pitanje za proveru znanja

P: Koliko minuta mesečno (30 dana) sme servis da bude nedostupan uz dostupnost od 99,9%? O: 43,2 minuta (0,1% od 43.200 minuta).

Tema 13 – Propusni opseg, iskorišćenost i baseline

1. Jednostavno objašnjenje

Monitoring meri koliko je „cev" (link) popunjena. Ako je internet veza od 100 Mb/s stalno popunjena 95%, korisnici će se žaliti na sporost, iako „sve radi".

2. Stručno objašnjenje

Propusni opseg (bandwidth) je nominalni kapacitet linka, a iskorišćenost (utilization) je deo kapaciteta koji se stvarno koristi. Iz SNMP brojača oktetâ računa se:

Iskorišćenost (%) = (Δoktetâ × 8) / (Δt × brzina linka) × 100

Primer: brojač ifHCInOctets porastao je za 1.125.000.000 bajtova za 300 s na linku od 100 Mb/s → 1.125.000.000 × 8 / 300 = 30.000.000 b/s = 30 Mb/s → 30%. Na uređaju se ista informacija vidi u show interfaces (redovi 5 minute input/output rate, txload/rxload), uz brojače grešaka (input errors, CRC, output drops) koji ukazuju na fizičke probleme ili zagušenje (Modul 20).

Baseline je izmereno normalno ponašanje mreže tokom dužeg perioda (tipična iskorišćenost po satima i danima, uobičajena latencija, broj grešaka). Bez baseline-a nije moguće reći da li je 60% iskorišćenosti u 11 časova normalno ili je znak problema. 95. percentil je standardna mera za planiranje kapaciteta i obračun kod provajdera: odbaci se 5% najviših uzoraka, pa kratkotrajni vrhovi ne utiču na procenu. Za detaljnu analizu „ko troši propusni opseg" koriste se NetFlow/IPFIX/sFlow podaci o tokovima saobraćaja.

3. Primer iz svakodnevnog života

Autoput sa tri trake (propusni opseg) i broj automobila koji njime prolaze (iskorišćenost). Gužva u 8 ujutru je normalna (baseline), ali gužva u 3 ujutru znači da se nešto desilo.

4. Primer iz poslovnog IT okruženja

Grafikon internet veze pokazuje da 95. percentil iskorišćenosti raste 5% mesečno i sada je 78%. Inženjer na osnovu trenda predlaže upravi povećanje brzine veze pre nego što korisnici počnu da primećuju usporenje.

5. Praktična vežba / napomena

Na ruteru u Packet Traceru izvršite show interfaces GigabitEthernet0/0 i pronađite: brzinu (BW), txload/rxload, 5 minute input rate i broj input errors.

6. Najčešće greške

• Zaključivanje na osnovu jednog trenutnog merenja umesto trenda.
• Proseci na dugim intervalima (dnevni prosek) koji sakrivaju kratkotrajna zagušenja.
• Ignorisanje brojača grešaka — spor link često nije pun, već ima fizički problem.

7. Pitanje za proveru znanja

P: Brojač se povećao za 750.000.000 bajtova za 300 s na linku od 1 Gb/s. Kolika je iskorišćenost? O: 750.000.000 × 8 / 300 = 20.000.000 b/s = 20 Mb/s, što je 2% od 1 Gb/s.

Tema 14 – Upozorenja (alerting)

1. Jednostavno objašnjenje

Upozorenje je poruka koju monitoring sistem šalje kada nešto pređe dogovorenu granicu. Dobra upozorenja su retka i važna; loša su česta i svi ih ignorišu.

2. Stručno objašnjenje

Upozorenje se definiše kao uslov (metrika, prag, trajanje) + ozbiljnost + primalac/kanal. Primeri: „uplink iskorišćenost > 85% duže od 15 minuta → upozorenje (Warning)", „uređaj ne odgovara na ping 3 uzastopne provere → kritično (Critical)". Dobre prakse:

• Trajanje i ponavljanje — ne okidati na jedan uzorak (izbegavanje lažnih upozorenja).
• Histereza — upozorenje se okida na 85%, a smiruje tek ispod 75%, da ne bi „treperilo".
• Nivoi ozbiljnosti — Info / Warning / Critical, sa različitim kanalima (e-pošta naspram SMS/poziva dežurnom).
• Zavisnosti — ako padne ruter lokacije, ne slati 40 upozorenja za svaki uređaj iza njega, već jedno (root cause).
• Svako upozorenje mora imati akciju — ako na upozorenje niko ne mora ništa da uradi, ono ne treba da postoji.

Zamor od upozorenja (alert fatigue) nastaje kada tim dobija previše nevažnih upozorenja, pa počne da ignoriše i ona važna. Periodi održavanja (maintenance window) privremeno isključuju upozorenja za uređaje na kojima se planirano radi.

3. Primer iz svakodnevnog života

Auto-alarm koji se oglasi na svaki prolazak kamiona — posle nedelju dana niko u ulici se više ne okreće, pa ni kada neko stvarno provali u auto.

4. Primer iz poslovnog IT okruženja

NOC tim dobija 2.000 e-poruka dnevno iz monitoring sistema i postavlja filter koji ih sve šalje u poseban folder. Kvar glavnog uplink-a ostaje nezapažen 40 minuta. Posle revizije ostaje 20 smislenih pravila sa zavisnostima, a kritična upozorenja idu SMS-om dežurnom.

5. Praktična vežba / napomena

Za internet vezu firme definišite dva upozorenja: jedno za dostupnost i jedno za iskorišćenost, sa pragom, trajanjem, ozbiljnošću i primaocem.

6. Najčešće greške

• Upozorenje na svaki pojedinačni uzorak iznad praga.
• Svi primaju sva upozorenja — niko se ne oseća odgovornim.
• Bez definisanih zavisnosti — jedan kvar izaziva lavinu upozorenja.
• Upozorenja koja se šalju samo e-poštom tokom noći, bez dežurstva.

7. Pitanje za proveru znanja

P: Šta je histereza kod upozorenja i čemu služi? O: Različit prag za aktiviranje i za smirivanje upozorenja (npr. 85% i 75%); sprečava da upozorenje stalno „treperi" kada vrednost osciluje oko jednog praga.

Tema 15 – Eskalacija i dokumentovanje incidenta

1. Jednostavno objašnjenje

Kada nastane problem, zna se ko ga prvi rešava, kome se prosleđuje ako ne uspe, i sve se zapisuje — da bi se problem brže rešio i da se ne bi ponovio.

2. Stručno objašnjenje

Incident je neplaniran prekid ili pogoršanje servisa; problem je (često nepoznat) uzrok jednog ili više incidenata (terminologija ITIL-a). Proces:

1. Detekcija i evidentiranje — upozorenje ili prijava korisnika otvara tiket sa vremenom, simptomom i obimom.
2. Klasifikacija prioriteta — prema uticaju (koliko korisnika/servisa) i hitnosti, npr. P1 (cela firma bez interneta) do P4 (kozmetički problem).
3. Eskalacija — funkcionalna (L1 help desk → L2 administrator → L3 inženjer/proizvođač) kada nivo nema znanje ili ovlašćenja, i hijerarhijska (obaveštavanje menadžmenta) za incidente visokog prioriteta. Matrica eskalacije definiše rokove: npr. P1 se eskalira na L2 ako nije rešen za 15 minuta.
4. Rešavanje i oporavak — vraćanje servisa (i privremeno rešenje).
5. Zatvaranje i dokumentovanje — zapisnik o incidentu (vremenska linija, uticaj, preduzete radnje, rešenje).
6. Analiza uzroka — izveštaj o problemu (post-mortem): osnovni uzrok (root cause, Modul 20), zašto nije ranije otkriven, i korektivne mere sa odgovornim osobama i rokovima. Dobra praksa je „blameless" pristup — traži se uzrok u procesu, ne krivac.

3. Primer iz svakodnevnog života

Hitna pomoć: dispečer procenjuje hitnost poziva (prioritet), ekipa na terenu pruža prvu pomoć (L1), a teški slučajevi se prevoze specijalisti u bolnici (eskalacija). Svaki slučaj ima karton sa vremenima i postupcima.

4. Primer iz poslovnog IT okruženja

U 9:05 monitoring javlja pad internet veze centrale (P1). L1 u 9:08 proverava napajanje modema i otvara tiket; posle 15 minuta bez rešenja eskalira na L2, koji utvrđuje kvar kod provajdera i prijavljuje ga. Veza se vraća u 10:20. Zapisnik o incidentu beleži celu vremensku liniju, a izveštaj o problemu predlaže rezervnu internet vezu drugog provajdera (Modul 26).

5. Praktična vežba / napomena

Otvorite šablone Zapisnik o incidentu i Izveštaj o problemu i uporedite koje podatke sadrži svaki od njih. Koristićete ih u laboratoriji.

6. Najčešće greške

• Incident rešen, ali ništa zapisano — isti problem se ponavlja i ponovo se rešava od nule.
• Predugo zadržavanje incidenta na L1 nivou bez eskalacije.
• Traženje krivca umesto uzroka — ljudi počinju da sakrivaju greške.
• Izveštaj o problemu bez konkretnih korektivnih mera, odgovornih osoba i rokova.

7. Pitanje za proveru znanja

P: Koja je razlika između zapisnika o incidentu i izveštaja o problemu? O: Zapisnik o incidentu opisuje šta se desilo i kako je servis vraćen (vremenska linija, uticaj, radnje); izveštaj o problemu analizira osnovni uzrok i definiše mere da se incident ne ponovi.

Rezime modula

• Dokumentacija opisuje kako je mreža izgrađena; nadzor prati kako mreža radi — potrebno je oboje.
• Osnovni dokumenti: inventar opreme, fizički i logički dijagram, IP adresni plan, VLAN tabela, evidencija portova — gotovi šabloni su u /sabloni.
• Dosledni nazivi uređaja i opisi portova (description) čine dokumentaciju delom same konfiguracije; CDP/LLDP pomažu u otkrivanju suseda.
• Backup konfiguracija: automatski, verzionisan, van uređaja, zaštićen i proveren vraćanjem.
• SNMP (UDP 161/162): polling i trap-ovi, MIB/OID; u produkciji v3 ili bar read-only v2c sa ACL-om.
• Syslog (UDP 514): nivoi 0–7, logging trap šalje izabrani nivo i ozbiljnije, NTP je preduslov za korisne logove.
• Monitoring sistemi (Zabbix, PRTG, LibreNMS, Grafana) objedinjuju prikupljanje, prikaz i upozorenja.
• Dostupnost i SLA, iskorišćenost linka iz SNMP brojača, baseline i 95. percentil.
• Smislena upozorenja sa trajanjem, histerezom i zavisnostima; jasna eskalacija i dokumentovanje incidenata i problema.

Mermaid dijagram

graph LR
    subgraph Uredjaji["Mrežni uređaji"]
        R["Ruter"]
        SW["Svičevi"]
    end
    R -->|"SNMP odgovor (UDP 161)<br/>Trap (UDP 162)"| NMS["Monitoring server<br/>(NMS)"]
    SW -->|"Syslog (UDP 514)"| NMS
    NTP["NTP server"] -->|"Tačno vreme"| R
    NTP -->|"Tačno vreme"| SW
    NMS -->|"Upozorenje"| NOC["NOC / dežurni"]
    NOC -->|"Eskalacija L1 → L2 → L3"| ENG["Inženjer"]
    ENG -->|"Zapisnik i izveštaj"| DOC["Dokumentacija"]

Dodatni izvori (opciono)

• RFC 5424 – The Syslog Protocol
• RFC 3411–3418 – SNMP arhitektura i SNMPv3
• Dokumentacija Zabbix-a (zabbix.com/documentation), LibreNMS-a (docs.librenms.org) i Grafana-e (grafana.com/docs)
• NetBox dokumentacija (netboxlabs.com/docs) — IPAM i inventar kao izvor istine
• ITIL 4 – Incident Management i Problem Management praksa