Teorija – Modul 10: Spanning Tree i redundansa

Redundantne veze između svičeva su dobra ideja — ako jedan link ili svič otkaže, mreža treba da nastavi da radi preko rezervnog puta. Problem je što svičevi, za razliku od rutera, ne razumeju "putanje" kroz mrežu na isti način — oni uče MAC adrese i flooduju frejmove čije odredište ne znaju. Kada postoji više fizičkih puteva između dva sviča, taj flooding može da kruži u krug zauvek. Ovaj modul objašnjava zašto se to dešava i kako protokol Spanning Tree (STP) to sprečava, a i dalje dozvoljava redundansu.

Tema 1: Problem mrežnih petlji (Switching Loops)

Jednostavno objašnjenje: Zamislite da imate dva izlaza iz sobe koja vode u isti hodnik. Ako neko u sobi vikne poruku i ona odjekne kroz oba izlaza, a hodnik je krug koji se vraća nazad u sobu kroz oba ulaza, ta poruka će odjekivati zauvek, sve glasnije, dok se soba ne ispuni bukom. To je mrežna petlja.

Stručno objašnjenje: Svič nema polje "Time to Live" (TTL) u Ethernet frejmu, za razliku od IP paketa na Layer 3. Kada svič dobije frejm za nepoznatu ili broadcast MAC adresu, on ga floduje na sve portove osim onog na kome je stigao. Ako u topologiji postoje dva ili više fizičkih puteva između istog para svičeva (redundantna veza), frejm se floduje unedogled u krug — svaki svič ga prosleđuje sledećem, koji ga prosleđuje nazad, i tako bez kraja. Ovo se zove switching loop ili Layer 2 loop.

Primer iz svakodnevnog života: Dva mikrofona postavljena jedan naspram drugog i oba povezana na isti pojačavač proizvode piskav "Larsenov efekat" (audio feedback) — zvuk se pojačava kružeći unedogled dok ne postane nepodnošljiv. Switching loop radi isti trik, samo sa mrežnim saobraćajem.

Primer iz poslovnog IT okruženja: U firmi Prima Trejd d.o.o. tehničar želi da poveća pouzdanost mreže u serverskoj sobi, pa dodaje drugi kabl između Access sviča i Distribution sviča "za svaki slučaj" — bez razmišljanja o STP-u. Za par sekundi cela mreža na tom spratu prestaje da radi: svič-ovi se preopterete brzinom obrade frejmova, help desk telefon počinje da zvoni sa svih strana zgrade.

Praktična vežba: Nacrtajte na papiru dva sviča povezana sa dva kabla (dva fizička linka između njih). Označite portove. Zamislite da računar A pošalje broadcast frejm. Pratite prstom kako se taj frejm množi i vraća kroz oba linka — nakon nekoliko "krugova" videćete da broj kopija frejma raste geometrijski.

Najčešće greške:

• Povezivanje dva porta istog sviča direktno kablom "da se testira" — ovo odmah pravi petlju.
• Verovanje da će mreža "sama nekako da se snađe" bez STP-a — bez STP-a, svič nema mehanizam da detektuje petlju.
• Zaboravljanje da isključi ili ukloni stari, zaboravljeni kabl nakon rekonfiguracije, čime se nesvesno pravi petlja.

Pitanje za proveru znanja: Zašto Ethernet frejm, za razliku od IP paketa, ne može sam da se "istroši" i nestane nakon određenog broja preskoka kroz mrežu?

Tema 2: Broadcast Storm

Jednostavno objašnjenje: Broadcast storm je posledica petlje — količina saobraćaja koja kruži kroz mrežu raste tako brzo da za nekoliko sekundi "guši" celu mrežu i sve normalne uređaje prestaju da mogu da komuniciraju.

Stručno objašnjenje: Kada broadcast frejm (npr. ARP zahtev) uđe u petlju, svaki svič ga umnožava na sve portove osim ulaznog. Sa dva sviča i dva linka između njih, jedan broadcast frejm se duplira pri svakom prolasku, a pošto nema TTL mehanizma koji bi ga zaustavio, broj kopija raste eksponencijalno dok ne zasiti celokupan raspoloživi propusni opseg linkova i CPU svičeva koji moraju da obrade svaku kopiju. Ovo se naziva broadcast storm. Posledice: mreža postaje potpuno neupotrebljiva, svičevi mogu da se restartuju usled preopterećenja CPU-a, legitimni saobraćaj se gubi.

Primer iz svakodnevnog života: Zamislite glasinu koja se širi na zabavi gde svako ko je čuje odmah prepriča svima oko sebe, uključujući i osobu od koje ju je čuo, koja je onda prepriča dalje — za par minuta svi u sali viču istu rečenicu jedni drugima i niko ne može normalno da razgovara.

Primer iz poslovnog IT okruženja: Mrežni tehničar u Prima Trejd d.o.o. dobija desetine žalbi u istom minutu — svi korisnici na spratu javljaju da im je "internet stao". Kada priđe svič ormanu, primećuje da sve LED diode na portovima sviča besomučno trepere iako niko ne radi ništa neuobičajeno — to je klasičan vizuelni znak broadcast storm-a.

Praktična vežba: Izračunajte: ako jedan broadcast frejm uđe u petlju sa dva sviča i svaki prolazak kroz oba sviča duplira broj kopija, koliko kopija frejma cirkuliše nakon 10 "krugova" (2^10)? Ovo pokazuje zašto broadcast storm nastaje za samo nekoliko sekundi.

Najčešće greške:

• Pokušaj rešavanja broadcast storm-a restartovanjem svičeva bez uklanjanja fizičke petlje — problem se odmah vraća čim se svič ponovo podigne.
• Nedovoljno brzo prepoznavanje simptoma (masovni prekid veze + treperenje svih LED dioda) kao znaka petlje, umesto trošenja vremena na proveru pojedinačnih računara.
• Ignorisanje broadcast storm-a kao "privremenog glitch-a" bez trajnog uklanjanja uzroka (dodatnog, neplaniranog kabla).

Pitanje za proveru znanja: Koja dva vizuelna/operativna simptoma pomažu tehničaru da odmah posumnja na broadcast storm, pre nego što uopšte otvori CLI sviča?

Tema 3: Nestabilnost MAC tabele

Jednostavno objašnjenje: Pored zagušenja saobraćajem, petlja pravi haos i u "memoriji" sviča koja pamti gde se koji uređaj nalazi — svič počinje da "menja mišljenje" o tome sa kog porta se stiže do određenog računara, više puta u sekundi.

Stručno objašnjenje: Svič uči MAC adrese na osnovu izvorišne adrese ulaznog frejma i porta na kome je stigao (MAC address table / CAM tabela, obrađeno u Modulu 8). U petlji, kopije istog frejma (sa istom izvorišnom MAC adresom pošiljaoca) stižu na svič sa više različitih portova, u brzoj sukcesiji, jer kruže kroz mrežu. Svič neprestano ažurira svoj zapis za tu MAC adresu, menjajući povezani port — ovo se naziva MAC address table instability ili MAC flapping. Posledica je da svič ne može pouzdano da zna kojim putem da pošalje frejm ka toj adresi, što dodatno povećava flooding (jer se svaki put frejm tretira kao da je odredišna MAC adresa "nepoznata").

Primer iz svakodnevnog života: Zamislite poštara koji pokušava da zapamti na kojem se spratu nalazi stanar "Petrović" — ali dobija kontradiktorne informacije svake minute (čas mu kažu treći sprat, čas prizemlje) jer glasine kruže kroz zgradu brže nego što on stigne da ih proveri. Poštar na kraju ne zna gde da ostavi paket.

Primer iz poslovnog IT okruženja: Tokom broadcast storm-a u Prima Trejd d.o.o., administrator proverava MAC tabelu sviča komandom show mac address-table i primećuje da se isti MAC unos menja između dva različita porta nekoliko puta u sekundi na svakom sledećem izvršavanju komande — jasan dokaz da postoji aktivna petlja, a ne samo zagušenje.

Praktična vežba: Zamislite da izvršite show mac address-table tri puta zaredom u razmaku od jedne sekunde i vidite da MAC adresa AAAA.BBBB.CCCC menja port sa Gi0/1 na Gi0/3 pa opet na Gi0/1. Objasnite svojim rečima šta ovo znači i šta biste prvo proverili fizički u ormanu.

Najčešće greške:

• Tumačenje MAC flapping-a kao kvara mrežne kartice na krajnjem uređaju, umesto kao simptoma petlje.
• Zanemarivanje show mac address-table kao dijagnostičkog alata tokom sumnje na petlju.
• Fokusiranje samo na zagušenje saobraćaja, a ignorisanje nestabilnosti tabele kao odvojenog, paralelnog problema koji dodatno otežava rad mreže.

Pitanje za proveru znanja: Zašto MAC flapping dodatno pogoršava broadcast storm, umesto da bude samo sporedna posledica?

Tema 4: STP – osnovni koncept

Jednostavno objašnjenje: Spanning Tree Protocol (STP) je "saobraćajac" koji automatski zatvara jedan od redundantnih puteva pre nego što petlja uopšte može da nastane, ali zna da ga ponovo otvori ako glavni put otkaže.

Stručno objašnjenje: STP (IEEE 802.1D) je protokol Layer 2 koji svičevi u istom broadcast domenu koriste da zajednički izgrade logičku topologiju bez petlji (drvo — "tree"), na osnovu fizičke topologije koja može imati redundantne (kružne) veze. STP to postiže tako što bira jedan svič kao root bridge (koren stabla), a zatim za svaki ostali svič određuje jedan port kao aktivan put ka root bridge-u, dok portove koji bi formirali alternativni (redundantni) put prebacuje u stanje blocking — oni fizički ostaju povezani i "osluškuju" mrežu, ali ne prosleđuju korisnički saobraćaj. Ako aktivna veza otkaže, STP automatski preračunava topologiju i aktivira prethodno blokiran port. Ključna ideja: redundansa ostaje fizički prisutna, ali je logički samo jedan put aktivan u svakom trenutku za dati VLAN.

Primer iz svakodnevnog života: Zamislite grad sa dva mosta koja povezuju dva dela grada preko reke. Da bi se izbegao saobraćajni haos ukrštanja, gradske vlasti odluče da samo jedan most bude otvoren za saobraćaj u datom trenutku, dok je drugi zatvoren rampom ali potpuno ispravan — ako se glavni most zatvori zbog radova, rampa na rezervnom mostu se odmah podiže.

Primer iz poslovnog IT okruženja: U Prima Trejd d.o.o., nakon incidenta sa broadcast storm-om iz Teme 1 i 2, administrator uključuje STP (koji je već podrazumevano aktivan na Cisco svičevima) i posmatra da drugi kabl između Access i Distribution sviča automatski prelazi u stanje blocking, dok se mreža odmah stabilizuje — bez fizičkog uklanjanja kabla.

Praktična vežba: Objasnite razliku između "fizičke topologije" (šta je stvarno povezano kablovima) i "logičke topologije" (šta STP dozvoljava da aktivno prosleđuje saobraćaj) na primeru dva sviča povezana sa dva kabla.

Najčešće greške:

• Isključivanje STP-a jer "smeta" ili "blokira port koji treba da radi", bez razumevanja da je to njegova namerna, zaštitna funkcija.
• Verovanje da blokiran STP port ne radi ili je pokvaren — on je namerno u stanju blocking, ne u kvaru.
• Mešanje pojmova "port je isključen" (shutdown) i "port je blokiran od strane STP-a" (blocking) — to su potpuno različita stanja.

Pitanje za proveru znanja: Šta se dešava sa logičkom (ne fizičkom) topologijom mreže u trenutku kada STP prebaci jedan port u stanje blocking?

Tema 5: BPDU (Bridge Protocol Data Unit)

Jednostavno objašnjenje: BPDU su kratke "poruke dogovora" koje svičevi razmenjuju međusobno da bi se usaglasili ko je "glavni" svič u mreži i koji portovi treba da budu aktivni, a koji blokirani.

Stručno objašnjenje: BPDU (Bridge Protocol Data Unit) je STP kontrolna poruka koju svičevi šalju jedni drugima na multicast MAC adresu 01:80:C2:00:00:00, podrazumevano na svakih 2 sekunde (Hello Timer). BPDU sadrži ključne informacije: Root ID (Bridge ID sviča za koji pošiljalac trenutno veruje da je root bridge), Sender Bridge ID (Bridge ID sviča koji šalje BPDU), Path Cost (ukupna cena puta od pošiljaoca do root bridge-a) i vrednosti tajmera (Hello Time, Max Age, Forward Delay). Postoje dve vrste: Configuration BPDU (redovna razmena tokom stabilnog rada) i Topology Change Notification (TCN) BPDU (šalje se kada svič detektuje promenu topologije, npr. link je pao ili se podigao). Na osnovu razmenjenih BPDU poruka, svičevi zajednički "biraju" root bridge i određuju uloge portova.

Primer iz svakodnevnog života: BPDU je kao razglednica koju svaki učesnik u izborima šalje ostalima na svakih par sekundi: "Ja mislim da je kandidat X trenutno vodeći, a ja sam udaljen Y koraka od njega." Kada svi prestanu da dobijaju te razglednice od nekoga, zaključuju da je taj učesnik "otpao" i ažuriraju svoje odluke.

Primer iz poslovnog IT okruženja: Administrator u Prima Trejd d.o.o. koristi Wireshark (Modul 19) da uhvati saobraćaj na trunk portu i vidi BPDU frejmove koji stižu na svakih 2 sekunde sa destinacijom 01:80:C2:00:00:00 — ovo mu potvrđuje da STP aktivno radi i da svičevi redovno razmenjuju informacije o topologiji.

Praktična vežba: Nabrojte tri ključna podatka koja BPDU nosi i objasnite zašto je "Path Cost" neophodan podatak za donošenje odluke o tome koji port treba da bude aktivan.

Najčešće greške:

• Mešanje BPDU sa običnim korisničkim (data) saobraćajem — BPDU je isključivo kontrolna poruka protokola, ne nosi korisničke podatke.
• Zaboravljanje da BPDU poruke nastavljaju da se razmenjuju i nakon što je topologija stabilna (ne samo tokom početnog izbora) — STP je kontinuiran proces, ne jednokratan događaj.
• Nerazumevanje da gubitak BPDU poruka (npr. usled kvara linka) pokreće ponovni proračun topologije.

Pitanje za proveru znanja: Šta se dešava ako svič prestane da prima BPDU poruke od svog suseda na aktivnom portu? Koji zaključak STP izvodi iz toga?

Tema 6: Root Bridge i STP Priority

Jednostavno objašnjenje: Pre nego što STP može da odluči koji portovi da blokira, svi svičevi se prvo moraju "dogovoriti" ko je od njih glavni — taj glavni svič se zove root bridge, i sve odluke o topologiji se prave u odnosu na njegovu poziciju u mreži.

Stručno objašnjenje: Svaki svič ima Bridge ID (BID) koji se sastoji od dva dela: STP Priority (podrazumevano 32768, podesiva u koracima od 4096, opseg 0–61440) i MAC adresa sviča. Root bridge se bira kao svič sa najmanjim (numerički najnižim) Bridge ID-jem u celoj STP domeni. Pošto se prvo poredi Priority, svič sa najnižom prioritetnom vrednošću automatski postaje root bridge, bez obzira na MAC adresu; MAC adresa služi samo kao "tie-breaker" kada dva sviča imaju istu (podrazumevanu) prioritetnu vrednost — tada pobeđuje svič sa numerički manjom MAC adresom. Pošto se root bridge bira automatski i podrazumevano na osnovu MAC adrese (koja se ne bira po dizajnu mreže), administrator po pravilu ručno podešava nižu Priority vrednost na svič koji želi da bude root bridge (obično centralni, najmoćniji Distribution ili Core svič), koristeći komandu spanning-tree vlan <broj> priority <vrednost> ili prečicu spanning-tree vlan <broj> root primary (koja automatski postavlja dovoljno nisku vrednost).

Primer iz svakodnevnog života: Zamislite izbor predsednika razreda gde svaki učenik ima "broj prioriteta" napisan na kartici, a pobeđuje onaj sa najmanjim brojem. Ako dva učenika imaju isti broj, pobeđuje onaj čije se prezime prvo pojavljuje po azbučnom redu (ekvivalent MAC adrese kao tie-breaker-a).

Primer iz poslovnog IT okruženja: U Prima Trejd d.o.o., administrator ručno postavlja Core svič (najsnažniji, u srcu mrežne infrastrukture) da bude root bridge komandom spanning-tree vlan 1 root primary, umesto da dozvoli da to slučajno postane stari, slabiji Access svič u magacinu samo zato što ima numerički manju MAC adresu.

Praktična vežba: Tri sviča imaju podrazumevanu Priority vrednost 32768 i MAC adrese: SW1 = AAAA.1111.1111, SW2 = AAAA.0000.2222, SW3 = BBBB.3333.3333. Odredite koji će svič postati root bridge i objasnite zašto.

Najčešće greške:

• Ostavljanje podrazumevanog prioriteta na svim svičevima, dozvoljavajući da MAC adresa (nasumičan faktor sa stanovišta dizajna mreže) odluči ko je root bridge.
• Postavljanje root bridge-a na slab, periferni svič umesto na centralni, snažan svič — ovo dodatno opterećuje mrežu jer sav STP-optimalan saobraćaj mora da prolazi kroz njega.
• Unos prioritetne vrednosti koja nije umnožak 4096 (npr. 5000), što IOS odbija.

Pitanje za proveru znanja: Ako dva sviča imaju identičnu STP Priority vrednost, koji dodatni podatak STP koristi da odluči ko postaje root bridge, i kako?

Tema 7: Root Port

Jednostavno objašnjenje: Root bridge je izuzet od pravila — ali svaki OSTALI svič mora da odabere tačno jedan svoj port kao "najbolji put nazad ka root bridge-u", i taj port se zove root port.

Stručno objašnjenje: Nakon što je root bridge izabran, svaki ne-root svič mora da odredi svoj root port (RP) — port sa najnižim ukupnim Path Cost-om do root bridge-a. Path Cost je zbir troškova (cost) svih linkova na putu do root bridge-a; podrazumevani trošak zavisi od brzine linka (npr. 100 Mb/s = 19, 1 Gb/s = 4, 10 Gb/s = 2, prema IEEE 802.1D standardu za revidirane vrednosti). Svaki ne-root svič ima tačno jedan root port. Ako postoji nerešeno stanje (isti Path Cost preko dva porta), STP koristi dodatne tie-breaker kriterijume: najniži Sender Bridge ID suseda, pa najniži Sender Port ID. Root bridge sam po sebi nema root port — svi njegovi aktivni portovi su designated portovi (Tema 8).

Primer iz svakodnevnog života: Ako živite u naselju sa više mogućih ruta do centra grada, svakog jutra birate onu koja vas najbrže odvede tamo (najniža "cena" u vidu vremena) — ta ruta je vaš lični "root port" ka centru, čak i ako postoje druge, sporije alternative.

Primer iz poslovnog IT okruženja: Access svič u Prima Trejd d.o.o. ima dve fizičke veze ka Distribution sloju: jednu preko 1 Gb/s linka (cost 4) i jednu preko rezervnog 100 Mb/s linka (cost 19). STP automatski bira 1 Gb/s link kao root port jer ima nižu ukupnu cenu, ostavljajući 100 Mb/s link kao rezervu.

Praktična vežba: Svič ima dva porta ka root bridge-u: Port A sa Path Cost 8 i Port B sa Path Cost 4. Koji port STP bira kao root port i zašto?

Najčešće greške:

• Zaboravljanje da root bridge nikada nema root port — pitanje "koji je root port root bridge-a?" je trik pitanje bez odgovora.
• Mešanje pojmova Path Cost (cena celog puta do root bridge-a) i cost pojedinačnog linka — Path Cost je zbir, ne pojedinačna vrednost.
• Ručno menjanje cost vrednosti bez razumevanja da to direktno utiče na to koji link postaje aktivan (root port) na svakom svič-u nizvodno.

Pitanje za proveru znanja: Zašto root bridge nema root port, za razliku od svih ostalih svičeva u mreži?

Tema 8: Designated Port i Blocked (Non-Designated) Port

Jednostavno objašnjenje: Za svaki fizički segment mreže (kabl ili deljeni link), samo jedan svič sa svake strane sme da aktivno prosleđuje saobraćaj na taj segment — taj port se zove designated port. Svi ostali portovi koji bi vodili ka istom segmentu, a nisu izabrani, prelaze u stanje blocking.

Stručno objašnjenje: Za svaki segment mreže (link između dva sviča, ili segment ka hubu), STP bira tačno jedan designated port (DP) — port koji pripada svič-u sa najnižim Path Cost-om do root bridge-a na tom segmentu; on aktivno prosleđuje saobraćaj ka/od tog segmenta. Svi portovi na root bridge-u su po definiciji designated portovi (jer imaju Path Cost 0 do samog sebe). Port na svič-u koji nije ni root port ni designated port za dati segment postaje blocked port (u terminologiji 802.1D: non-designated port, u stanju blocking) — on je fizički povezan i prima BPDU poruke, ali ne prosleđuje korisnički saobraćaj, čime se sprečava petlja. Ako se aktivna veza pokvari, STP ponovo preračunava topologiju i taj port može preći u aktivno stanje.

Primer iz svakodnevnog života: Na raskrsnici sa semaforima, u svakom trenutku samo jedan pravac ima zeleno svetlo (designated), dok ostali pravci čekaju sa crvenim (blocked) — ali svi vozači i dalje mogu da vide raskrsnicu i spremni su da krenu čim njihovo svetlo postane zeleno.

Primer iz poslovnog IT okruženja: Između Distribution sviča i Access sviča u Prima Trejd d.o.o. postoje dva fizička kabla. STP određuje da je port na Distribution svič-u koji vodi ka primarnom kablu designated, dok se odgovarajući port na drugom, rezervnom kablu na Access svič-u postavlja u blocking — čime se garantuje da postoji tačno jedan aktivan put između njih u svakom trenutku.

Praktična vežba: Nacrtajte tri sviča povezana u trougao (SW1–SW2, SW2–SW3, SW1–SW3, sve tri veze aktivne fizički). Ako je SW1 root bridge, odredite koji su portovi root, koji designated, a koji će verovatno biti blocked, imajući u vidu da svaka veza mora imati tačno jedan designated port sa svake strane.

Najčešće greške:

• Verovanje da "blocked" znači da je port pokvaren ili administrativno isključen (shutdown) — on je namerno u stanju blocking radi sprečavanja petlje, i i dalje prima/šalje BPDU poruke.
• Zaboravljanje da svaki fizički segment (ne svič) ima tačno jedan designated port — na segmentu sa hubom i tri sviča, samo jedan od njih dobija ulogu designated za taj segment.
• Nerazumevanje da root bridge nikada nema blocked portove — svi njegovi portovi su designated.

Pitanje za proveru znanja: Da li blocked port i dalje prima BPDU poruke, ili je potpuno "gluv" za mrežni saobraćaj? Zašto je odgovor važan za razumevanje kako STP kasnije reaguje na kvar aktivnog linka?

Tema 9: STP Portna Stanja i Konvergencija

Jednostavno objašnjenje: Port ne postaje odmah aktivan čim se poveže kabl — STP ga prvo provuče kroz nekoliko "probnih" faza pre nego što mu dozvoli da počne da prosleđuje korisnički saobraćaj, a ceo taj proces (dok se cela mreža ne stabilizuje) zove se konvergencija.

Stručno objašnjenje: Klasičan STP (802.1D) definiše sledeća portna stanja:

Prelazak iz Blocking u Forwarding kod klasičnog 802.1D STP-a traje podrazumevano oko 30-50 sekundi (Listening 15s + Learning 15s, plus Max Age tajmer od 20s ako se čeka na detekciju gubitka BPDU), što se naziva STP konvergencija. Ovo dugo vreme je glavna mana klasičnog STP-a — tokom tog perioda, uređaji povezani na taj port ne mogu da komuniciraju sa mrežom (npr. DHCP zahtev računara koji se upravo pokreće može da istekne pre nego što port pređe u Forwarding).

Primer iz svakodnevnog života: Kao kada ulazite u zamračenu bioskopsku salu — prvo stojite na vratima i pustite oči da se priviknu na mrak (Listening), zatim polako tražite slobodno mesto oslanjajući se na obrise koje nazirete (Learning), i tek onda sednete i počnete da gledate film (Forwarding). Ceo taj proces traje neko vreme, čak i ako znate tačno gde želite da sednete.

Primer iz poslovnog IT okruženja: Zaposleni u Prima Trejd d.o.o. se žali da mu računar "ne dobija IP adresu odmah nakon paljenja" kada je povezan na port koji tek prolazi kroz STP konvergenciju — DHCP zahtev se gubi jer port još nije u stanju Forwarding, pa računar mora da sačeka sledeći DHCP pokušaj (obrađeno detaljnije u Modulu 13, a razlog kašnjenja objašnjen upravo ovde i u Temi 10 kroz PortFast).

Praktična vežba: Poređajte sledeća stanja hronološkim redom kako ih port klasičnog STP-a prolazi kada se prvi put poveže: Forwarding, Blocking, Learning, Listening.

Najčešće greške:

• Očekivanje da port odmah nakon povezivanja kabla počne da prosleđuje saobraćaj — klasičan STP uvek prolazi kroz Listening i Learning faze prvo.
• Mešanje stanja Blocking (deo normalnog STP procesa/ishoda) sa Disabled (administrativno isključen port) — ovo su različiti koncepti.
• Nerazumevanje zašto se DHCP ili PXE boot process ponekad "ne uspe" na prvi pokušaj na sporim STP portovima.

Pitanje za proveru znanja: Zašto klasičan STP namerno provlači port kroz Listening i Learning faze umesto da ga odmah prebaci u Forwarding?

Tema 10: PortFast i BPDU Guard

Jednostavno objašnjenje: Za portove koji sigurno vode ka običnom uređaju (računaru, štampaču), a ne ka drugom svič-u, ne treba nam ceo spori proces konvergencije — PortFast to ubrzava, a BPDU Guard nas štiti u slučaju da nas smo prevarili sami sebe i tamo je ipak povezan svič.

Stručno objašnjenje: PortFast je konfiguracija na nivou interfejsa koja govori STP-u da odmah prebaci taj konkretan port iz Blocking direktno u Forwarding, preskačući Listening i Learning faze — namenjen isključivo access portovima ka krajnjim uređajima (računar, štampač, IP telefon), gde je fizički nemoguće da nastane petlja. PortFast se nikada ne sme koristiti na portovima koji povezuju dva sviča jer to zaobilazi normalnu sigurnosnu proveru STP-a i može izazvati privremenu petlju. Da bi se ta greška sprečila, koristi se BPDU Guard — ako port sa uključenim PortFast-om i BPDU Guard-om ikada primi BPDU poruku (što znači da je na njega neko slučajno ili namerno povezao svič, a ne krajnji uređaj), port se automatski prebacuje u stanje err-disabled (administrativno gašenje zbog greške) radi zaštite cele mreže.

Primer iz svakodnevnog života: PortFast je kao VIP ulaz na koncert za ljude koje već poznajete i kojima verujete — ne moraju da čekaju u redu za proveru (Listening/Learning). BPDU Guard je alarm koji se automatski oglasi i zatvori taj VIP ulaz ako neko nepoznat (BPDU, odnosno drugi svič) pokuša da uđe kroz njega.

Primer iz poslovnog IT okruženja: IT administrator u Prima Trejd d.o.o. konfiguriše sve access portove u kancelarijama sa spanning-tree portfast i spanning-tree bpduguard enable. Kada jedan zaposleni samoinicijativno donese mali kućni svič i poveže ga na zidnu utičnicu da bi priključio i laptop i telefon, port se automatski gasi (err-disabled) čim kućni svič pošalje svoj prvi BPDU, sprečavajući potencijalnu petlju bez potrebe da administrator uopšte fizički interveniše na vreme.

Praktična vežba: Objasnite zašto bi uključivanje PortFast-a BEZ BPDU Guard-a na portu gde neko slučajno poveže dodatni svič moglo privremeno da izazove petlju, dok bi PortFast SA BPDU Guard-om tu istu situaciju bezbedno rešio.

Najčešće greške:

• Uključivanje PortFast-a na trunk portovima ili portovima između svičeva — najozbiljnija i najčešća greška, direktno ugrožava stabilnost mreže.
• Uključivanje BPDU Guard-a bez PortFast-a i neočekivano gašenje legitimnih portova (retko potrebno van PortFast konteksta, pažljivo planirati).
• Zaboravljanje da err-disabled port zahteva ručnu (ili automatski tajmeraisanu, ako je konfigurisano) intervenciju da bi se ponovo aktivirao.

Pitanje za proveru znanja: Šta se dešava sa portom koji ima uključen i PortFast i BPDU Guard, ako neko na njega poveže dodatni svič umesto računara?

Tema 11: RSTP (Rapid Spanning Tree Protocol)

Jednostavno objašnjenje: RSTP je poboljšana, brža verzija STP-a koja postiže isti cilj (sprečavanje petlji uz zadržavanje redundanse), ali se oporavlja od promena u mreži za sekunde umesto za desetine sekundi.

Stručno objašnjenje: RSTP (IEEE 802.1w), na Cisco opremi dostupan kao Rapid PVST+ po VLAN-u, rešava glavni nedostatak klasičnog STP-a — sporu konvergenciju. Ključne razlike: RSTP svodi portna stanja na tri (Discarding — spaja stara Blocking/Listening/Disabled, Learning, Forwarding) i uvodi nove portne uloge: pored Root i Designated porta, dodaje Alternate port (rezervni put ka root bridge-u, brzo preuzima ulogu root porta ako glavni otkaže) i Backup port (rezervni designated port na istom deljenom segmentu). RSTP koristi aktivnu razmenu poruka (proposal/agreement mehanizam) između suseda umesto pasivnog čekanja na isticanje tajmera, čime konvergencija pada na red veličine sekundi, umesto 30-50 sekundi kod klasičnog STP-a. RSTP je unazad kompatibilan sa uređajima koji još uvek koriste klasičan 802.1D STP.

Primer iz svakodnevnog života: Klasičan STP je kao vatrogasna ekipa koja prvo mora da sačeka potvrdu preko spore radio veze pre nego što krene u akciju. RSTP je kao ekipa sa modernim, trenutnim sistemom komunikacije — čim jedan pravac postane nedostupan, odmah znaju tačno koji rezervni pravac da aktiviraju, bez čekanja.

Primer iz poslovnog IT okruženja: Prima Trejd d.o.o. nadograđuje svu svič infrastrukturu sa klasičnog STP-a na Rapid PVST+ nakon što je incident sa pucanjem jednog kabla izazvao skoro minut prekida za sve zaposlene na spratu — sa RSTP-om, identičan budući događaj bi izazvao prekid od samo par sekundi.

Praktična vežba: Nabrojte tri portne uloge koje RSTP dodaje ili menja u odnosu na klasičan STP, i objasnite ulogu Alternate porta svojim rečima.

Najčešće greške:

• Verovanje da je potrebno ručno konfigurisati svaku portnu ulogu — RSTP, kao i STP, radi automatski na osnovu BPDU razmene.
• Mešanje pojmova Alternate port (rezervni root port) i Backup port (rezervni designated port na istom segmentu) — imaju različite uloge.
• Zaboravljanje da promena STP moda (spanning-tree mode) mora biti konzistentna kroz celu mrežu radi maksimalne koristi, iako pojedinačni RSTP svič ostaje kompatibilan sa starijim STP susedima.

Pitanje za proveru znanja: Koja je osnovna razlika u brzini konvergencije između klasičnog STP-a i RSTP-a, i zbog čega je ta razlika bitna u produkcionoj poslovnoj mreži?

Tema 12: EtherChannel, LACP i PAgP

Jednostavno objašnjenje: Umesto da STP blokira jedan od dva paralelna kabla između svičeva "da bi izbegao petlju", možemo te kablove da "zalepimo" u jednu logičku vezu koja koristi oba istovremeno — to je EtherChannel, i STP ga tada tretira kao samo jedan link.

Stručno objašnjenje: EtherChannel (opšti pojam; Cisco implementacija Link Aggregation-a) grupiše 2 do 8 fizičkih portova između istog para uređaja u jedan logički interfejs (Port-channel), povećavajući ukupnu propusnost i pružajući redundansu unutar same grupe — ako jedan fizički link u grupi otkaže, saobraćaj se automatski preraspoređuje na preostale, bez ikakve STP rekonvergencije, jer STP celu grupu vidi kao jedan jedini logički link. Postoje dva protokola za pregovaranje (negotiation) EtherChannel-a između dva sviča:

• LACP (Link Aggregation Control Protocol, IEEE 802.3ad) — standardizovan, radi između opreme različitih proizvođača. Režimi: active (aktivno inicira pregovaranje) i passive (odgovara samo ako sused inicira). Bar jedna strana mora biti u režimu active.
• PAgP (Port Aggregation Protocol) — Cisco-ov proprietarni protokol, stariji, radi samo između Cisco uređaja. Režimi: desirable (aktivno inicira) i auto (odgovara samo ako sused inicira). Bar jedna strana mora biti u režimu desirable.

Postoji i režim on, koji prisilno formira EtherChannel bez ikakvog protokola za pregovaranje i proveru kompatibilnosti — ne preporučuje se u produkciji jer ne detektuje pogrešnu konfiguraciju na drugoj strani.

Primer iz svakodnevnog života: Umesto jedne trake za vožnju između dva grada koja bi bila usko grlo, gradite auto-put sa dve trake koje se tretiraju kao jedan pravac putovanja — više vozila prolazi istovremeno, a ako se jedna traka zatvori zbog radova, saobraćaj se jednostavno prelije na preostalu traku bez zaustavljanja celog pravca.

Primer iz poslovnog IT okruženja: Prima Trejd d.o.o. povezuje Distribution i Core svič sa dva fizička 1 Gb/s kabla konfigurisana kao EtherChannel (LACP, channel-group 1 mode active na oba sviča), dobijajući efektivno 2 Gb/s propusnosti i, ako jedan kabl fizički otkaže, saobraćaj se nesmetano nastavlja preko preostalog bez ikakvog STP prekida — jer STP od početka vidi samo jedan Port-channel interfejs, ne dva pojedinačna porta.

Praktična vežba: Objasnite zašto STP nikada ne blokira nijedan fizički port unutar ispravno konfigurisane EtherChannel grupe, za razliku od dva potpuno odvojena, negrupisana linka između istih svičeva.

Najčešće greške:

• Postavljanje nekompatibilnih režima na dve strane veze (npr. LACP passive na obe strane, ili LACP na jednoj strani i PAgP na drugoj) — EtherChannel se nikada ne formira.
• Dodavanje portova različitih brzina ili duplex podešavanja u istu EtherChannel grupu — svi fizički članovi moraju imati identične karakteristike.
• Zaboravljanje provere show etherchannel summary nakon konfiguracije, što ostavlja neotkrivenu grešku (portovi ostaju pojedinačni umesto "bundled").

Pitanje za proveru znanja: Zašto je EtherChannel, sa stanovišta STP-a, drugačiji pristup redundansi u odnosu na običnu STP blokadu drugog paralelnog kabla?

Tema 13: Redundansa linkova – praktična primena

Jednostavno objašnjenje: Sada kada znamo kako STP, PortFast, BPDU Guard, RSTP i EtherChannel rade pojedinačno, možemo da ih kombinujemo da napravimo mrežu koja je i brza, i bezbedna, i preživljava kvar pojedinačnog kabla ili sviča bez prekida rada.

Stručno objašnjenje: Projektovanje redundantne Layer 2 mreže u praksi kombinuje sve prethodne koncepte:

1. Redundantni fizički linkovi se postavljaju između ključnih svičeva (npr. Access ↔ Distribution, Distribution ↔ Core) kako bi se izbegla pojedinačna tačka otkaza (single point of failure).
2. RSTP (Rapid PVST+) se koristi umesto klasičnog STP-a radi brze konvergencije u slučaju kvara.
3. Root bridge se namerno, ručno postavlja na centralni, najsnažniji svič (obično Core ili Distribution) komandom spanning-tree vlan <broj> root primary, sa jasno definisanim sekundarnim kandidatom (root secondary).
4. PortFast + BPDU Guard se primenjuju na svim access portovima ka krajnjim uređajima radi brzine i zaštite.
5. Gde je moguće, EtherChannel zamenjuje parove paralelnih linkova između istih svičeva radi kombinovanja propusnosti i redundanse bez STP blokiranja.

Ova kombinacija daje mrežu koja: (a) nema petlje zahvaljujući STP/RSTP, (b) brzo se oporavlja od kvara linka ili sviča, (c) brzo aktivira nove korisničke portove bez nepotrebnog čekanja, i (d) štiti samu sebe od slučajnog povezivanja neovlašćenog sviča od strane korisnika.

Primer iz svakodnevnog života: Dobro projektovan gradski saobraćajni sistem ima alternativne puteve, semafore koji brzo reaguju na zagušenja, jasno definisane glavne magistrale (root bridge ekvivalent) i rampe za brz ulazak/izlazak lokalnog saobraćaja (PortFast ekvivalent) — sve zajedno čini sistem otporan na pojedinačne kvarove.

Primer iz poslovnog IT okruženja: Mrežni inženjer u Prima Trejd d.o.o. dokumentuje finalni dizajn mreže: Core svič je root primary za sve VLAN-ove, Distribution svič je root secondary, svi linkovi Distribution↔Core su EtherChannel (LACP active/active), svi Access↔Distribution linkovi su redundantni parovi zaštićeni RSTP-om, a svi korisnički portovi imaju PortFast i BPDU Guard. Test kvara (fizičko isključivanje jednog kabla) pokazuje prekid od manje od 2 sekunde, umesto ranijih 30-50 sekundi.

Praktična vežba: Na osnovu prethodnih 12 tema, sastavite kratku listu od 5 koraka koje biste, kao mrežni tehničar, primenili prilikom projektovanja nove redundantne mreže sa tri sviča — ovo će vam poslužiti kao priprema za laboratorijsku vežbu ovog modula.

Najčešće greške:

• Dodavanje redundantnih linkova bez prethodnog planiranja root bridge-a, ostavljajući izbor "slučaju" (najnižoj MAC adresi).
• Zaboravljanje da se PortFast/BPDU Guard primenjuju SAMO na portove ka krajnjim uređajima, nikada na portove između svičeva.
• Nedostatak dokumentacije mrežnog dizajna, što otežava budući troubleshooting kada nastane problem.

Pitanje za proveru znanja: Nabrojte najmanje četiri STP/redundansa koncepta iz ovog modula koje biste primenili zajedno prilikom projektovanja nove poslovne mreže sa tri sviča, i ukratko objasnite ulogu svakog.

Vizuelni prikaz: Problem petlje i STP rešenje

graph LR
    subgraph "Bez STP - Broadcast Storm"
    A1[Svič A] ---|Link 1| B1[Svič B]
    A1 ---|Link 2 - petlja!| B1
    end

graph TD
    R[Root Bridge<br/>Priority 4096] -->|Designated Port| SW2[Svič 2<br/>Root Port aktivan]
    R -->|Designated Port| SW3[Svič 3<br/>Root Port aktivan]
    SW2 -.->|Blocked Port - rezerva| SW3
    SW3 -.->|Blocked Port - rezerva| SW2

    style R fill:#4CAF50,color:#fff
    style SW2 fill:#2196F3,color:#fff
    style SW3 fill:#2196F3,color:#fff

Na drugom dijagramu, veza između Svič 2 i Svič 3 fizički postoji (isprekidana linija), ali je logički blokirana STP-om — ona postaje aktivna tek ako jedna od veza ka Root Bridge-u otkaže.