A 2. rétegben kezelt keretek fejlécében nem találunk olyan mezőt, amely ellátná azt a feladatot, amelyért a 3. rétegben az IP protokoll time-to-live mezője felelős, vagyis annak detektálása, hogy az adott csomag hurokba kerül. Ilyen hurkok akkor alakulnak ki, ha alternatív útvonalak is rendelkezésre állnak a hálózatban két eszköz között. Mivel a 2. rétegben a kapcsolók üzenetszórás vagy elárasztás esetén minden portjukon (kivéve ahol bejött) kiküldik keretet, üzenetszórási vihart, instabil MAC-cím táblát és duplikáltan megkapott kereteket kapunk eredményül. Ennek következtében a hálózatunk drasztikusan belassul és használhatatlanná válik. Ez ellen véd minket az STP protokoll, amelyet jelentősen továbbfejlesztettek, és a Cisco a saját verzióit több olyan funkcióval is kibővítette, melyek a protokoll működését biztonságosabbá tették. Ezeket vegyük most sorra.
Root Guard
A Root guard funkcióval meg tudjuk akadályozni, hogy egy portból gyökérponti port váljon. (Emlékezzünk rá, minden nem gyökérponti kapcsoló egyetlen gyökérponti port kerül kijelölésre, amelyről a legkisebb költséggel lehet elérni a gyökérponti hidat.) Ha egy Root Guard funkciót bekapcsoljuk egy porton, és az egy feljebbvaló BPDU-t (Superior BPDU) kap, akkor a port ErrDisabled állapotba kerül. (Ebből az állapotból az sh és no sh parancsok egymás utáni kiadásból lehet kiléptetni.) A funkció használatával megakadályozhatjuk, hogy a hálózathoz utólagosan (például egy PC által elfoglalt portra) csatlakoztatott kapcsoló átvegye a gyökérponti kapcsoló helyét.
Az alábbi topológián SW1 a gyökérponti híd. Annak érdekében, hogy ezt a szerepet ne tudják elvenni tőle, a topológián RG betűkkel jelölt portokon bekapcsoljuk a Root Guard-ot. Ügyeljünk arra, hogy SW2 és SW3 között ne alkalmazzuk ezt a lehetőséget, hiszen így a megmarad annak a lehetősége, hogy a működő kapcsolat kiesése esetén új kapcsolat léphessen a helyébe.
A Root Guard funkció bekapcsolása a következő paranccsal történhet:
SW2(config)#int fa0/1
SW2(config-if)#spanning-tree guard root
A kapcsoló miután megkap egy BPDU-t, a következő lépéseken végighaladva dönt úgy, hogy a kapott BPDU superior-e:
- A beérkező BPDU-ban tárolt gyökérponti híd BID értéke kisebb, mint a kapcsoló által tárolt gyökérponti híd BID értéke.
- Amennyiben a két (tehát a kapott és a tárolt) gyökérponti híd BID értéke azonos, a kapott BPDU-ban tárolt gyökérponti hídhoz vezető útvonal költsége kisebb.
- Ha ez a költség is azonos, akkor amennyiben a küldő kapcsoló BID értéke kisebb, mint a fogadó kapcsoló BID értéke.
- Ha ez az érték is azonos (vagyis a küldő és fogadó kapcsoló azonos, tehát a kapcsoló két portja ugyanahhoz a szegmenshez kacsolódik), a küldő port ID-ja kisebb, mint a fogadó porté.
STP portfast
Amikor az STP konvergál, és kiosztja a megfelelő port szerepeket, és beállítja ezek szerint a működési módokat, nagyon sok idő tud eltelni. (Alapértelmezetten akár 50 másodperc is!) Mivel ezen idő alatt nincsen adatforgalom, előfordulhat, hogy például a PC-k nem kapják meg dinamikusan az IP címinformációikat a DHCP szervertől. Ennek elkerülésére szolgál a portfast funkció, mely a hozzáférési (access) módban működő portokat azonnal továbbító állapotba helyezi, így azok adatforgalma azonnal megindulhat. (Persze a késleltetés problémáját nem oldja meg, ha a hálózat többi kapcsolója között még sokáig tart ez a folyamat.) Jegyezzük meg, a portfast funkció csak addig működik, amíg a porton nem érkezik egy BPDU üzenet, ugyanis akkor kikapcsolja a funkciót a porton és megkezdi a konvergálás folyamatát. (Vagyis ha az egyik hozzáférési módba kapcsolt PC-t kicseréljük egy kapcsolóra, amely elkezdi küldeni a BPDU-kat.)
Az alábbi topológiában a PF betűjelekkel jelöljük azokat a portokat, amelyeken érdemes a portfast funkciót bekapcsolni. A topológián jelöltük az egyes linkeken az adott portok módját is. (A: hozzáférési, T: trunk) Magyarázatra egyedül a szerverhez vezető link szorul. Vannak olyan hálózati kártyák, amelyek képesek a különböző VLAN-ok kezelésére és trönk kapcsolat kialakítására, melyeket tipikusan szerverekben alkalmazunk. Ezek számára is beállítható a portfast funkció.
A portfast funkció hozzáférési módú portokon az alábbi paranccsal konfigurálható:
SW2(config)#int fa0/2
SW2(config-if)#switchport mode access
SW2(config-if)#spanning-tree portfast
Míg trunk módú porton:
SW3(config)#int fa0/4
SW3(config-if)#switchport mode trunk
SW3(config-if)#spanning-tree portfast trunk
Ügyeljünk arra, hogy mindkét esetben csak olyan portokon alkalmazzuk a portfast funkciót, amelyek egyetlen állomáshoz csatlakoznak, vagyis kapcsolóhoz, HUB-hoz és bridge-hez kapcsolódó portokon ne, mert azokon átmeneti hurkokat okozhat.
Lehetőségünk van egyetlen paranccsal a kapcsoló valamennyi hozzáféréi módban működő portján bekapcsolni a portfast funkciót:
SW3(config)#spanning-tree portfast default
Annak leellenőrzése, hogy mely portokon működik a portfast funkció, a következő paranccsal lehetséges:
SW2#sh spanning-tree int fa0/2 detail | i portfast
The port is in the portfast edge mode
A portfast funkció kikapcsolásához használjuk a disable paramétert:
SW2(config)#int fa0/2
SW2(config-if)#spanning-tree portfast disable
BPDU Guard
A BPDU Guard funkció bekapcsolásával elérhetjük, hogy amennyiben azokon a portokon, amelyeken bekapcsoltuk a portfast funkciót, BPDU érkezik, a port automatikusan lekapcsol és ErrDisabled állapotba kerül. (Emlékezzünk rá, enélkül a port kilép portfast módból, és megkezdi a feszítőfa újraépítését.) A funkciót globálisan bekapcsolhatjuk minden portfast portra, vagy egyesével portonként:
SW2(config)#spanning-tree portfast bpduguard default
SW2(config)#interface fa0/1
SW2(config-if)#spanning-tree bpduguard enable
A funkció kikapcsolása a disable paraméterrel történik. Azt hogy egy porton be van-e állítva a funkció, a korábban látott paranccsal kell lekérdezni:
SW2#show spanning-tree interface fa0/1 detail | i Bpdu guard
Bpdu guard is enabled by default
Az ErrDisabled állapotba került port visszakapcsolása (sh és no sh) rendszergazdai feladat. Annak érdekében, hogy csökkentsük a rendszergazda feladatait, ez rábízható magára a kapcsolóra is az Error Recovery szolgáltatás segítségével. A szolgáltatásnak paraméterként lehet átadni, hogy milyen hibaesemény után vegye ki automatikusan a portot a hibaállapotból. (Érdemes a lehetőségeket a ? kapcsolóval lekérdezni.) A BPDU Guard által okozott hibaállapotból való kiléptetés az alábbi módon konfigurálható:
SW2(config)#errdisable recovery cause bpduguard
A szolgáltatás állapota adott hibaeseményre is lekérdezhető:
SW2#sh errdisable recovery | i bpduguard
bpduguard Enabled
A parancs kimenetének a végén láthatók azok a portok, amelyek valamilyen hiba miatt kerültek lekapcsolásra, és mellettük az az idő másodpercen, amennyi idő után a szolgáltatás megvizsgálja, hogy visszakapcsolhatja-e. Ennek az időintervallumnak az alapértelmezett értéke 300 másodperc (5 perc), mely az errdisable recovery interval time paranccsal 5 és 86400 másodperc között állítható. A show errdisable recovery paranccsal ellenőrizhetjük le, hogy milyen eseményeket figyel a szolgáltatás.
BPDU filter
A BPDU fileter funkcióval meg tudjuk akadályozni, hogy egy port BPDU-kat küldjön ki. (Nem csak a sajátjait, hanem másoktól kapott BPDU-kat se.) Konfigurálása globálisan vagy port szinten történhet. A funkció működése viszont függ a konfiguráció módjától.
Globálisan a spanning-tree portfast bpdufilter default paranccsal konfigurálhatjuk a funkciót, mely a már portfast portokon fejti ki hatását. Ilyenkor a port az első 10-12 inicializáló BPDU-t még kiküldi, de utána már semmilyent. Amennyiben viszont a port bejövő BPDU-t kap, akkor mind a portfast, mind a BPDU filter funkció kikapcsolódik rajta.
Ha port szinten kapcsoljuk be a szűrést (amely nem függ a port portfast konfigurációjától) a spanning-tree bpdufilter enable paranccsal, akkor nem küld ki BPDU-kat, a bejövő BPDU-kat pedig nem dolgozza fel.
A BPDU filter a BPDU Guard-dal szemben nem kapcsolja le a portot ErrDisabled állapotba BPDU fogadása esetén. Általában a Guard-ot érdemes használni, hiszen a portfast funkciót végfelhasználói berendezések portjain alkalmazzuk, melyekre előreláthatóan csak nem felügyelt módon (támadó szándékkal) csatlakoztathatnak kapcsolót, így jogos, ha erre a port lekapcsolásával reagálunk. Abban az esetben viszont, ha a hálózatunkat saját magunknak egy kapcsolóval kell bővíteni, de nincsen időnk ellenőrizni az STP fára kifejtett hatását, a csatlakoztatandó portra alkalmazzuk a BPDU szűrést, így az új kapcsoló által küldött BPDU-kat nem kell figyelembe venni.
Az egyirányú kapcsolatok problémája
A mai nagysebességű kapcsolókat már optikai szálakkal is össze lehet kötni, viszont a kétirányú kapcsolathoz két optikai szál szükséges, melyeken külön-külön egy irányban lehet az adatokat küldeni. Ha közülük az egyik optikai szál megszakad, akkor előállhat olyan eset, hogy az egyik kapcsoló egy másik gyökérponti portot választ, ezen fogadja a forgalmat, de az előző kapcsolat ép vonalán küldi vissza az adatokat. Ennek eredményeként továbbítási hurok jöhet létre. Ennek elkerülésére hozták létre a következő két funkciót:
STP Loop Guard
Az előző pontban bemutatott egyirányú kapcsolat problémájára ad megoldást az STP Loop Guard funkció, mely megakadályozza azt, hogy egy gyökérponti vagy egy alternatív portból kijelölt port legyen. Emlékezzünk arra, hogy egy konvergált hálózatban a gyökérponti kapcsoló, mint a legmagasabb szintű kapcsoló, BPDU-kat küld a kijelölt portjain (neki csak az van!) az alsóbbrendű kapcsolóknak, melyek ezeket a gyökérponti portjaikon fogadják. Persze az alsóbbrendű kapcsolók között is ilyen értelemben van hierarchia, hiszen ha egy alsóbbrendű kapcsoló a gyökérponti portján BPDU-t kap (amelyet ugye a gyökérponti kapcsoló küldött), akkor ezt továbbküldi a kijelölt portjain a többi kapcsolónak, amelyek ezt a gyökérponti portjukon fogadják, és így tovább. Nomármost, az STP Loop Guard azt akadályozza meg, hogy a gyökérporti (és az alternatív) portokból kijelölt portok váljanak. Ezt úgy teszi, hogy érzékeli, ha a portokon BPDU-t kell küldeni és nem fogadni, és a portot ErrDisabled állapotba helyezi.
A konfigurálása ismét vagy globálisan a spanning-tree loopguard default, vagy port szinten a spanning-tree guard loop paranccsal történhet.
A Loop Guard és a Root Guard funkciók egyidejűleg nem alkalmazhatók.
Unidirectional Link Detection (UDLD)
Az UDLD mechanizmus is az olyan 1. rétegbeli fizikai hibák ellen véd, mint a kétirányú optikai szálak egyik irányának megszakadás, vagy más hasonló vezetékezési hibák. Gyakorlatilag ha engedélyezzük az UDLD-t a portokon, akkor olyan UDLD üzeneteket küld a másik oldalnak, melyben elhelyezi a saját rendszer és port azonosítóját, amelyeket visszavár. Ha nem kapja meg azokat, akkor feltételezi, hogy megszakadt a visszirányú kapcsolat. Kétféle módban tud működni: normál és agresszív módba. Normál módban, ha nem érkeznek meg a válaszok, akkor a portot aktív módban hagyja, de a kapcsolatot meghatározatlannak tekinti. Agresszív módba, ha nem érkezik meg a válasz, akkor még próbálkozik 8 üzenettel, utána a portot hibaállapotba helyezi. A funkciót az udld enable paranccsal engedélyezhetjük, lekérdezésére pedig a show udld neighbors és a show udld interface paranccsal történik.
