A redundancia a hierarchikus hálózattervezés fontos eszköze a hálózati szolgáltatások zavarainak megelőzésére. A redundáns hálózatokhoz további fizikai útvonalak hozzáadása szükséges, de a tervezés során a logikai redundanciát is szem előtt kell tartani. Ugyanakkor a kapcsolt Ethernet hálózatban a redundáns útvonalak egyaránt vezethetnek fizikai és 2. rétegbeli hurkok keletkezéséhez.

A 2. rétegbeli logikai hurkok a kapcsolók természetes működése miatt jönnek létre, konkrétan az automatikus tanulás és továbbítás módszer miatt. Amikor két eszköz között több út is létezik és a kapcsolók nem használnak feszítőfa megoldásokat, 2. rétegbeli hurok jön létre. Ez három fő problémát okoz:

• Szórási viharok - Ha nem működik valamilyen hurokelkerülési eljárás, minden kapcsoló szakadatlanul szórásos keretekkel árasztja el a hálózatot.

• MAC-adatbázis instabilitás - Ha ugyanaz a keret a kapcsoló több portjára is beérkezik, instabillá válhat a MAC-címtábla tartalma. Az adattovábbítás károkat szenvedhet, ha a kapcsoló arra használja fel erőforrásainak egy részét, hogy kezelje a MAC-címtábla instabilitásával járó gondokat.

• Duplikált egyedi keretek - Az egyedi küldésű keretek több példányban juthatnak el a célállomáshoz. Sok protokoll van, amely nincs felkészítve rá, hogy egy-egy üzenet többször jusson el hozzá. Ha ugyanaz a keret több példányban érkezik be, helyrehozhatatlan hibák következhetnek be.

Szórási viharnak (broadcast storm) nevezzük, amikor olyan sok szórásos keret kerül bele a 2. rétegbeli hurokba, hogy ez a teljes sávszélességet felemészti. Következésképpen a valódi forgalom számára nem marad elérhető sávszélesség, a hálózat elérhetetlenné válik. Ez tulajdonképpen egyfajta szolgáltatásmegtagadás (Denial of Service, DoS).

Hurkot tartalmazó hálózatban a szórási vihar elkerülhetetlen. Ahogy egyre több eszköz küld szórásos forgalmat, egyre több keret kerül bele a hurokba és emészti fel az erőforrásokat. Ez végül szórási viharhoz vezet és a hálózat nem működik többé.

A szórási viharoknak vannak egyéb következményei is. Mivel a szórásos forgalmat minden kapcsoló minden portján továbbítja, minden hozzá csatlakoztatott eszköznek szintén fel kell dolgoznia a hurokban végtelenségig továbbított szórásos kereteket. Ez a végberendezések hibás működéséhez is vezethet, mivel a nagy forgalom leterheli a hálózati kártya feldolgozóegységét.

Szórási vihar akár másodpercek alatt is kialakulhat, mert a hálózat eszközei rendszeresen küldenek szórásos kereteket, ilyenek például az ARP-kérések is. Emiatt egy hurok kialakulása után a kapcsolt hálózat nagyon gyorsan összeomlik.

Az Ethernet kereteknek nincs élettartam (time to live, TTL) tulajdonságuk. Emiatt nincs beépített megoldás az ellen, hogy a kapcsolók a kereteket végtelenségig, vagy valamelyik kapcsolat megszakadásáig (és ezzel a hurok megszűnéséig) továbbítsák egymás között. A szórásos keretek ezen folytonos továbbítása okozza a MAC-adatbázis instabilitást.

A szórásos keretek minden kapcsolóporton továbbítódnak az eredeti beérkező portot kivéve. Ez biztosítja azt, hogy a szórási tartomány minden eszköze megkapja a keretet. Ha több úton lehet a keretet a cél felé továbbítani, végtelen hurok jöhet létre. Amikor a hurok létrejön, a kapcsoló MAC-cím táblázata a szórásos keretek alapján folyamatosan változni fog, ami MAC-adatbázis instabilitáshoz vezet.

SW_A# show mac-address-table | include 0030.1904.da60
   1    0030.1904.da60    DYNAMIC     Fa0/10
SW_A# show mac-address-table | include 0030.1904.da60
   1    0030.1904.da60    DYNAMIC     Fa0/10
SW_A# show mac-address-table | include 0030.1904.da60
   1    0030.1904.da60    DYNAMIC     Fa0/2
SW_A# show mac-address-table | include 0030.1904.da60
   1    0030.1904.da60    DYNAMIC     Fa0/3
SW_A# show mac-address-table | include 0030.1904.da60
   1    0030.1904.da60    DYNAMIC     Fa0/2

Ez a folyamat ismétlődik újra és újra mindaddig, amíg a hurkot alkotó valamelyik kapcsolatot fizikailag meg nem szüntetjük, vagy a hurokban részt vevő valamelyik kapcsolót le nem kapcsoljuk. Ez a hurokban szereplő minden kapcsolón magas processzorhasználatot okoz, mivel a kapcsolók ugyanazt a keretet továbbítják folyamatosan oda-vissza. A valódi forgalom feldolgozása emiatt lelassul.

A hurokban érintett állomás nem képes elérni a hálózat többi állomását, mivel a MAC-táblázat folyamatos változása miatt a kapcsoló nem tudja, hogy az egyedi kereteket melyik portjára kellene továbbítania. A fenti példában a kapcsolók helytelen portot tárolnak a PC1-hez. Minden a PC1-nek címzett egyedi keret szintén belekerül a hurokba a szórásos keretek mellé, így egyre több keret szorul be, a hálózat szórási vihart generál.

A hurkok nem csak a szórásos kereteket érintik. A hurkot tartalmazó hálózatba küldött egyedi keretek esetenként megkettőzve érnek a céljukhoz.

A legtöbb felsőbb rétegbeli protokoll nincs felkészítve arra, hogy felismerje a duplikált üzeneteket. Általában véve a sorszámozást használó protokollok azt feltételezik, hogy az átvitel sikertelen volt és a sorszámot újra felhasználták egy másik kommunikációs munkamenetben. Más protokollok a duplikált forgalmat továbbítják a megfelelő felsőbb protokoll számára, hogy feldolgozza, esetleg eldobja azt.

A 2. rétegbeli LAN-protokollok, amilyen az Ethernet is, nem tartalmaznak mechanizmust a végtelenségig keringő üzenetek felismerésére. Bizonyos 3. rétegbeli protokollok TTL-alapú (élettartam) módszerrel korlátozzák le, hogy a Layer 3 eszközök legfeljebb hányszor továbbíthassák a csomagot. A 2. rétegbeli eszközök nem használnak ilyet, a hurokba került forgalmat végtelenségig továbbítják. A probléma kiküszöbölésére az STP-t, a 2. rétegbeli hurok elkerülésére szolgáló módszert fejlesztették ki.

Az ilyen problémák megelőzésére a redundáns hálózatokban valamilyen feszítőfa protokollt kell engedélyeznünk a kapcsolókon. A 2. rétegbeli hurkok megelőzésének érdekében a feszítőfa a Cisco kapcsolókon alapértelmezés szerint engedélyezve van.

A redundancia úgy növeli a hálózat rendelkezésre állását, hogy megvédi a hálózatot a kritikus pontok (egyetlen kábel vagy kapcsoló) meghibásodásának hatásaitól. Amikor egy hálózatba fizikai redundanciát építünk, hurkok keletkezhetnek és duplikált keretek jöhetnek létre. Mindkettő súlyos következményekkel járhat a kapcsolt hálózat működésére nézve. A probléma megoldására fejlesztették ki a feszítőfa protokollt (Spanning Tree Protocol, STP).

Az STP biztosítja, hogy a hálózat bármely két eszköze között csak egy logikai útvonal létezzen, mivel a hurok keletkezéséhez vezető redundáns utakat lezárja. A lezárt porton nem érkezik és nem távozik felhasználói adat. Ez nem érinti az STP által használt BPDU-kereteket (Bridge Protocol Data Unit, hídprotokoll adategység). A redundáns útvonalak lezárása a hurkok megelőzésének legfontosabb eleme. A fizikai útvonalak a redundancia érdekében továbbra is léteznek, de a hurkok megelőzése miatt letiltottak. Ha hálózati kábel vagy kapcsoló hibája miatt ismét szükség lenne az útvonalra, az STP újratervezi azokat és szükség szerint engedélyezi a korábban lezárt portokat.

Az STP hurokmentes útvonalakat hoz létre portok lezárásával a hálózat megfelelő pontjain. Az STP a hálózat hibáit úgy javítja, hogy a korábban lezárt portokat újra aktiválja és így a forgalom egy alternatív útvonalon továbbhaladhat.

A módszerre eddig a feszítőfa protokoll kifejezést és angol rövidítését, az STP-t használtuk. Azonban a kifejezés és a rövidítés használata bizonyos esetekben félrevezető lehet. A szakemberek ezt a rövidítést a feszítőfa különböző megvalósításainak közös említésekor használják, ilyenek például a Rapid Spanning Tree Protocol (RSTP) és a Multiple Spanning Tree Protocol (MSTP). Ha helyesen szeretnénk a feszítőfa módszerek elveiről beszélni, fontos, hogy a megfelelő konkrét megvalósítási módot vagy szabványt említsük. A feszítőfa legutolsó IEEE dokumentuma (IEEE-802-1D-2004) szerint „az STP-t mostanra leváltotta az RSTP”. Az IEEE az STP alatt a feszítőfa eredeti megvalósítását érti, az RSTP alatt pedig az IEEE-802-1D-2004-ben leírt változatot. Ebben a tananyagban, amikor az eredeti feszítőfa protokollt tárgyaljuk, a félreértések elkerülése végett úgy hivatkozunk rá, hogy „az eredeti 802.1D feszítőfa”. Mivel a két protokoll nagy része ugyanazt a terminológiát és módszereket használja, elsősorban a jelenlegi szabványokra és az STP és az RSTP Cisco általi megvalósításaira fogunk koncentrálni.

Megjegyzés: Az STP egy Radia Perlman által kifejlesztett algoritmuson alapul, amelyet akkor alkotott meg, amikor a Digital Equipment Corporationnál dolgozott. 1985-ös publikációjának eredeti címe „An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN”

A feszítőfa algoritmus (STA) segítségével az STP egy hurokmentes topológiát hoz létre a következő négy lépcsős folyamat alkalmazásával:

1. Gyökérponti híd kiválasztása
2. Gyökérportok kiválasztása
3. Kijelölt portok kiválasztása
4. Alternatív (blokkolt) portok kiválasztása

A kapcsolók a feszítőfa algoritmus- és az STP-funkciók megvalósítása során BPDU (Bridge Protocol Data Units) üzeneteket használnak a magukról és kapcsolataikról szóló információk megosztására. A BPDU-kat a gyökérponti híd, a root portok, a kijelölt portok és az alternatív portok kiválasztására használják. Minden BPDU tartalmaz egy hídazonosítót (BID), amely azonosítja a BPDU küldőjét. A BID alapját képezi az STA-döntések meghozatalának, beleértve a gyökérponti híd-funkció és a port szerepek kiosztását is. Amint az ábrán látható, a BID tartalmaz egy prioritási értéket, egy kiterjesztett rendszer-azonosítót és a kapcsoló MAC-címét. A legalacsonyabb BID értéket e három mező kombinációja határozza meg.

Híd prioritási érték

A Cisco kapcsolók alapértelmezett prioritási értéke a 32768 decimális érték. A tartomány 0-tól 61440-ig terjed, 4096-os ugrásokkal használható. Egy alacsonyabb híd prioritás érték előnyt jelent. A 0-ás híd prioritása érték elsőbbséget élvez az összes többi híd prioritás értékkel szemben.

S1(config)# spanning-tree vlan 1 priority  ?
  <0-61440>  bridge priority in increments of 4096

Lehetséges STP/RSTP prioritás értékek

Kiterjesztett rendszer-azonosító

A kiterjesztett rendszer-azonosító egy decimális száméték, melyet a BPDU VLAN-jának azonosítására szolgál. Ez az érték hozzáadódik a BID-en belüli híd prioritási értékéhez.

A korai IEEE 802.1D (STP) szabványt olyan hálózatokhoz tervezték, amelyek még nem használtak VLAN-okat. Az összes kapcsoló egyetlen közös feszítőfához tartozott. Emiatt a régebbi kapcsolóknál a kiterjesztett rendszer-azonosító nem szerepelt a BPDU-kban. Amint a VLAN-ok használata általános megoldássá vált a hálózati infrastruktúra szegmentálásában, a 802.1D tovább bővült a VLAN-ok támogatásával, melynek következtében szükségessé vált egy 12 bites VLAN azonosító felvétele a BPDU keretbe. A VLAN információk a kiterjesztett rendszer-azonosító használatával kerülnek be a BPDU keretbe.

A kiterjesztett rendszer-azonosító használata lehetővé teszi, hogy különböző VLAN-ok számára más-más gyökérponti hidat használhassunk. Ezáltal lehetségessé válik, hogy például egy bizonyos VLAN-ba tartozó redundáns, nem továbbító linkeket egy másik VLAN-ban adattovábbításra használjuk, egy másik gyökérponti híd segítségével.

MAC cím

Amennyiben két kapcsoló azonos prioritási értékkel van konfigurálva, és ugyanazokkal a kiterjesztett rendszer-azonosítókkal rendelkeznek, akkor a legkisebb értékű MAC-címmel rendelkező kapcsoló fog az alacsonyabb BID-értékkel rendelkezni.

Az STA kiválaszt egy kapcsolót, amelyet gyökérponti hídnak (root bridge) nevezünk, ez lesz minden útvonalszámítás referencia pontja. Az STP-ben részt vevő összes kapcsoló BPDU-kereteket vált egymással, hogy meghatározzák, melyiküknek a legalacsonyabb a hídazonosítója (bridge ID, BID) a hálózatban.

A gyökérponti híd meghatározása választási folyamat során történik. A szórási tartomány minden kapcsolója részt vesz a választásban. Miután egy kapcsoló elindul, két másodpercenként BPDU-kereteket kezd küldeni, melyek a kapcsoló hídazonosítóját és a gyökér azonosítóját (Root ID) tartalmazzák.

A legalacsonyabb hídazonosítójú kapcsoló lesz automatikusan az STA-számítások gyökérponti hídja. A szórási tartomány minden kapcsolója úgy indítja a feszítőfa algoritmust, hogy saját magát képzeli gyökérponti hídnak, a kiküldött BPDU-keretekben saját hídazonosítója lesz a gyökér azonosító. Amikor a kapcsolók elküldik BPDU-keretüket, a szomszéd kapcsolóik megnézik a BPDU-keret gyökér azonosító mezőjét. Ha az érkezett BPDU gyökér azonosítója alacsonyabb, mint a fogadó kapcsoló root ID-je, a kapcsoló frissíti a gyökér azonosítóját és a szomszéd kapcsolót fogja gyökérponti hídként elismerni. Ez nem mindig a tényleges szomszédot jelenti, lehet a szórási tartomány bármelyik kapcsolója is. Ezután a kapcsoló továbbküldi az új BPDU-kereteket az alacsonyabb gyökér azonosítóval a szomszédainak. A folyamat végére a legalacsonyabb hídazonosítójú kapcsolót fogja gyökérponti hídként ismerni az egész feszítőfa.

Az alapértelmezett hídazonosítók hatása

Amennyiben a hálózati topológiában található kapcsolók azonos hídprioritás-értékkel rendelkeznek (32768), illetve azonos VLAN-ba tartoznak (pl. VLAN 1), a legalacsonyabb hídazonosító értékét a legalacsonyabb értékű kapcsoló MAC cím fogja meghatározni.

Gyökérponti híd rendszergazda által történő kiválasztása

Amikor a rendszergazda egy bizonyos kapcsolót szeretne gyökérponti híddá tenni, a hídprioritását úgy kell beállítania, hogy a hálózat összes többi kapcsolójáénál alacsonyabb legyen. Cisco Catalyst kapcsolón két módszert használhatunk a hídprioritás beállítására:

1. módszer

Állítsuk a kapcsoló prioritását a legalacsonyabb értékre a spanning-tree vlan vlan-azonosító root primary globális konfigurációs paranccsal. A kapcsoló prioritása az előre meghatározott 24576 érték lesz, vagy a hálózatban érzékelt legalacsonyabb hídprioritásnál kisebb olyan szám, amely a legnagyobb 4096 többszörös.

Ha másodlagos gyökérponti hidat is szeretnénk beállítani, használhatjuk a spanning-tree vlan vlan-azonosító root secondary globális konfigurációs parancsot. Ez a parancs a kapcsoló prioritását az előre meghatározott 28672-re állítja. Így az elsődleges gyökérponti híd meghibásodása esetén ez lesz a gyökérponti híd. Feltételezzük, hogy a hálózat többi kapcsolójának a prioritása az alapértelmezett 32768.

2. módszer

A hídprioritás konfigurálásának egy másik módszere, ha a spanning-tree vlan vlan-azonosító priority érték globális konfigurációs parancsot használjuk. Ez a hídprioritás finomabb szabályozását teszi lehetővé. A prioritás értéke 0 és 61440 közé eshet 4096-os lépésekben.

Egy kapcsoló hídprioritását a show spanning-tree paranccsal ellenőrizhetjük.

Amint egy feszítőfa példány kiválasztotta a gyökérponti hídját, az STA megkezdi a szórási tartomány minden eszközétől a gyökérponti híd felé vezető legjobb útvonalak meghatározását. Egy útvonal össszköltsége a gyökérponti híd felé vezető útvonalon levő portok költségeinek összege. A legalacsonyabb költségű útvonal a legelőnyösebb, minden más redundáns útvonal pedig le lesz tiltva.

Megjegyzés: A BPDU tartalmazza a gyökérútvonal költségét. Ez a küldőkapcsolótól a gyökérhídig vezető út költsége.

Amikor egy kapcsolóhoz egy BPDU érkezik, a kapcsoló hozzáadja a BPDU-ban szereplő gyökérútvonal költséghez annak a saját portjának a költségét, melyen a BPDU-t fogadta. Ezáltal végzi el a belső gyökérútvonalának meghatározását (a gyökérhídig mért teljes útvonal költségét).

Az alapértelmezett portköltséget egy adott port működési sebessége határozza meg. A táblázat az IEEE által javasolt alapértelmezett portköltségeket mutatja. A Cisco kapcsolók alapértelmezés szerint az IEEE 802.1D szabvány által meghatározott értékeket, más néven rövid útvonal költségeket használják mind az STP, mind az RSTP számára. Az IEEE szabvány azonban javasolja az IEEE-802.1w-ben (más néven hosszú útköltség) meghatározott értékek használatát 10 Gbps-os és gyorsabb kapcsolatok használatakor.

Habár a kapcsolóportokhoz alapértelmezett költség értéket rendeltek, az érték konfigurálható. A rendszergazda az egyes portok költségének beállításával rugalmasan képes befolyásolni a gyökérponti hídhoz vezető feszítőfa utakat.

Egy interfész port költségének beállításához a „spanning-tree cost <érték>” parancsot használhatjuk interfész konfigurációs módban. Az érték 1 és 200 000 000 közé eshet.

Portköltség beállítása:

S1(config)# interface FastEthernet 0/1
S1(config-if)# spanning-tree cost 1

Portköltség visszaállítása:

S1(config)# interface FastEthernet 0/1
S1(config-if)# no spanning-tree cost

A port és útvonal költségek lekérdezése a „show spanning-tree” paranccsal lehetséges. A parancskimenet felső részén található „Cost” mező értéke a gyökérponti hídig vezető útvonal teljes költsége. Ez függ attól is, hogy hány kapcsolóporton keresztül vezet út a gyökérponti hídig.

S1# show spanning-tree 
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    32769
             Address     000C.8555.9B62
             Cost        19
             Port        1(FastEthernet0/1)
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     00D0.97B3.96E9
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/2            Altn BLK 19        128.2    P2p
Fa0/1            Root FWD 19        128.1    P2p

A gyökérponti híd meghatározását követően az STA algoritmus következő feladata a gyökérportok kiválasztása lesz.

Amikor egy kapcsoló a gyökérportját próbálja meghatározni, összehasonlítja az összes, a feszítőfában részt vevő portjának útvonal költségeit. A legalacsonyabb összköltségű útvonallal rendelkező port automatikusan gyökérport lesz, hiszen ő van a legközelebb a gyökérponti hídhoz. Egy kapcsolt hálózatban minden olyan kapcsolónak, amely nem gyökérponti híd, egyetlen gyökérportja lesz, az amelyik a gyökérponti híd felé a legalacsonyabb költségű utat biztosítja. Egy kapcsoló gyökérponti hídig mért teljes útvonal költségét belső gyökérút költségnek nevezzük. A belső gyökérút költsége megegyezik az összes portköltség összegével a gyökérponti hídhoz vezető út mentén. A feszítőfa protokoll a legalacsonyabb költségű utakat részesíti előnyben, és minden más felesleges útvonalat blokkol.

Gyökérport kiválasztása több azonos költségű útvonalak esetén

A gyökérport és a kijelölt portok kiválasztása a gyökérhídhoz vezető út legkisebb költségén alapszik. De mi történik, ha a kapcsolónak több azonos költségű útvonallal rendelkezik a gyökérhídhoz? Hogyan fogja kinevezni a gyökérportját? Ilyen esetben a kapcsoló az alábbi kritériumok alapján dönt:

1. Legalacsonyabb küldői hídazonosító
2. Legalacsonyabb küldői port-prioritás
3. Legalacsonyabb küldői portazonosító

1. Legalacsonyabb küldői hídazonosító

2. Legalacsonyabb küldői port-prioritás

3. Legalacsonyabb küldői portazonosító

Miután a kapcsoló meghatározta a gyökérportokat, meg kell állapítania, hogy melyek lesznek a kijelölt és az alternatív (blokkolt) portok.

A nem gyökérponti kapcsolók nem gyökérportjai kijelölt vagy alternatív portok lesznek.

Minden LAN-szegmensen (összeköttetésen) van kijelölt port. Két azonos szegmensen levő kapcsoló a gyökérportok meghatározása után eldönti, hogy melyik port legyen kijelölt port és melyik marad alternatív port.

A kijelölt port küld és fogad forgalmat a szegmensről, mivel rajta keresztül vezet a legjobb útvonal a gyökérponti hídhoz. Az alternatív port nem fogad és nem is küld forgalmat.

Minden kapcsoló meghatározza portjainak szerepét, hogy végül hurokmentes feszítőfa jöjjön létre.

Gyökérponti híd kijelölt portjai

A gyökérponti híd automatikusan minden portját kijelölt porttá teszi (D). Ennek oka, hogy a gyökérponti hídnak saját maga felé a legalacsonyabb a költsége.

Kijelölt port, ha van gyökérport

Ha a hálózati szegmens egyik végén gyökérport található, a másik végén kötelező módon kijelölt portnak kell lennie.

Megjegyzés: Minden olyan kapcsoló port, melyhez végberendezés (hoszt) csatlakozik, kijelölt port szerepkört fog kapni.

Kijelölt port, ha nincs gyökérport

Olyan két kapcsoló közötti szegmensen kerülhet beállításra ahol egyik kapcsoló sem gyökérponti híd

Ebben az esetben a kapcsoló azon portja, amelyik a legkevesebb költséggel rendelkezik a gyökérponti hídhoz mérve, a szegmens kijelölt portja lesz.

Ha egy kapcsolóport nem gyökérport vagy kijelölt port, akkor alternatív (vagy tartalék) port lesz belőle. Az alternatív portok és a tartalék portok eldobási (discarding) vagy blokkolási (blocking) állapotban vannak, a hurkok megakadályozása érdekében. Az összes többi kapcsoló-közi port pedig továbbítási (forwarding) állapotban lesz. Ez képezi tulajdonképpen az STP hurokmegelőzési részét.

Az STP konvergenciához három időzítő szükséges, az alábbiak szerint:

• Hello Timer - A hello idő a BPDU-k közötti időintervallumot jelenti. Az alapértelmezett érték 2 másodperc, de módosítható 1 és 10 másodperc közötti értékre.

• Továbbítási késleltetési időzítő (Forward Delay Timer) - A továbbítási késleltetés az az idő, amelyet a kapcsolók a figyelési (listening) és tanulási (learning) állapotban töltenek. Az alapértelmezett érték 15 másodperc, viszont 4 és 30 másodperc közötti értékre módosítható.

• Max Age Timer - A maximális életkor az a maximális idő, amelyre egy kapcsoló vár, mielőtt megpróbálja megváltoztatni az STP topológiát. Az alapértelmezett érték 20 másodperc, de módosítható 6 és 40 másodperc közötti értékre.

Megjegyzés: Az alapértelmezett időzítő-értékek kizárólagosan a gyökérponti hídon módosíthatóak. Az itt beállított időzítő-értékek lesznek érvényesek STP tartomány egészére.

Az STP logikai hurokmentes utakat hoz létre egy adott üzenetszórási tartományon belül. Az feszítőfa a BPDU keretek kapcsolók közötti cseréjével megismert információk alapján kerül meghatározásra. Ha egy kapcsolóport közvetlenül a blokkolt állapotból az továbbító állapotba vált, anélkül, hogy az átmenet során a teljes topológiáról lenne információja, a port ideiglenesen létrehozhat egy adathurkot. Emiatt az STP öt portállapotot határoz meg, melyek közül négy operatív portállapot, amint azt a következő ábra is mutatja. A kikapcsolt portállapot működésképtelennek minősül.

Megjegyzés: Az STP-vel kapcsolatos problémák elkerülése érdekében az IEEE az alapértelmezett STP időzítők alkalmazása mellet legfeljebb hét kapcsolóból álló hálózati átmérő használatát javasolja.

A port állapotok részletes leírása a következő táblázatban található:

Az eredeti IEEE 802.1D óta a feszítőfa protokolloknak számos változata jelent meg.

Ezek közül néhány:

STP szabványok és konfigurációs lehetőségek

A kapcsolók üzemeltetéséért felelős hálózati szakembernek kell döntenie a használni kívánt feszítőfa protokoll változatról.

Az újabb IOS-verziót futtató Cisco kapcsolók, mint a 15.0-s IOS-sal rendelkező Catalyst 2960, alapértelmezés szerint PVST+-t futtatnak. Az újabb kapcsolók az IEEE 802.1D-2004 specifikáció több összetevőjét megvalósítják, ilyen az alternatív port szerep a korábbi nem kijelölt port helyett. Azonban, ha a gyors feszítőfa protokollt szeretnénk használni, még az újabb kapcsolókon is kifejezetten be kell ezt állítanunk.

S1(config)# spanning-tree mode ?
  mst         Multiple spanning tree mode
  pvst        Per-Vlan spanning tree mode
  rapid-pvst  Per-Vlan rapid spanning tree mode

Az RSTP (IEEE 802.1w) az eredeti 802.1D továbbfejlesztése, amelyet beépítettek az IEEE 802.1D-2004 szabványba. A 802.1w STP terminológiája megegyezik az eredeti IEEE 802.1D STP-vel. A legtöbb paraméter változatlan maradt, az STP-t ismerő szakemberek könnyen be tudják konfigurálni az új protokollt is. Úgy az STP, mit az RSTP ugyanazt a feszítőfa algoritmust használja a port szerepek és topológia meghatározásához.

Az RSTP felgyorsítja a feszítőfa újraszámítását a 2. rétegbeli topológia változásakor. Sokkal gyorsabb konvergenciát lehet vele elérni egy megfelelően konfigurált hálózatban, néha mindössze néhány száz milliszekundumon belül. Az RSTP újradefiniálja a port típusokat és állapotaikat. Egy alternatív vagy tartalék port azonnal továbbító állapotba léphet, nem kell megvárni a hálózat konvergálását.

Megjegyzés: A Rapid PVST+ az RSTP VLAN-onkénti Cisco megvalósítása. Minden VLAN-hoz független RSTP-példány fut.

Az STP három lehetséges működési állapota (letiltott, lezárt, figyelő) gyakorlatilag egyetlen port állapottá olvadt össze (eldobási) az RSTP esetén.

A gyökérportok és a kijelölt portok mind az STP, mind az RSTP esetében megegyezőek. Van azonban két RSTP port szerepkör, amelyek az STP lezárt állapotának felel meg. Az STP-ben a lezárt portot úgy definiálják, hogy nem kijelölt vagy gyökérport. Az RSTP-nek két port szerepköre van meghatározva erre a célra.

Az alternatív port egy olyan port, mely rendelkezik alternatív útvonallal a gyökérponti hídhoz. A biztonsági port egy osztott közeg (pl. HUB) másodlagos portja. A biztonsági port ritkábban fordul elő, mivel a HUB-okat ma már régi, elavult hálózati eszközöknek tekintik.

A PortFast a Cisco PVST+ környezetben használt funkciója. A PortFast beállítás a kapcsolóportot lezárt állapotból azonnal továbbító állapotba váltja, amellyel megkerüli a szokásos 802.1D STP állapotátmeneteket (a figyelő és a tanuló állapotokat). A PortFast arra szolgál, hogy a hozzáférési portok eszközei azonnal elérjék a hálózatot, ne kelljen megvárniuk az IEEE 802.1D STP konvergálását minden egyes VLAN-on. Hozzáférési porton az egyetlen munkaállomást vagy szervert csatlakoztató portot értjük.

Szabályos PortFast beállítások esetén sosem érkezhetnek BPDU-k, mert ez azt jelentené, hogy a portra másik híd vagy kapcsoló csatlakozik, ami feszítőfa hurokhoz vezethetne. A Cisco kapcsolók egy BPDU-védelemnek (BPDU guard) nevezett funkciót is támogatnak. Ha engedélyezzük, a BPDU-védelem a portot error-disabled állapotba helyezi, ha azon BPDU érkezik. Ez gyakorlatilag leállítja (shutdown) a portot. A BPDU-védelem biztonságos megoldás a hibás konfigurációk ellen, mert az interfészt csak manuálisan lehet újból üzembe helyezni.

A Cisco PortFast technológia DHCP használata esetén is hasznos. PortFast nélkül egy PC még azelőtt küldhetne DHCP-kérést, hogy a port továbbító állapotba kerülne, így nem kapna használható IP-címet és konfigurációt. A PortFast azonnal továbbító módba állítja a portot, így a PC mindig kap IP-címet.

Megjegyzés: Mivel a PortFast célja, hogy a hozzáférési portoknak a lehető legkevesebbet kelljen a feszítőfa konvergálására várakozniuk, a beállítást csak azokon szabad használni. Másik kapcsolóhoz csatlakozó porton használva feszítőfa hurok létrejöttét kockáztatjuk.

A PortFast és a BPDU-védelem alapértelmezés szerint minden interfészen ki van kapcsolva.

S1(config)# interface FastEthernet 0/1
S1(config-if)# spanning-tree portfast

S1(config)# spanning-tree portfast default 

S1(config)# interface FastEthernet 0/1
S1(config-if)# spanning-tree bpduguard enable

S1(config)# spanning-tree portfast bpduguard default 

S1# show running-config
...
!
spanning-tree mode pvst
spanning-tree portfast default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
!
interface FastEthernet0/1
 spanning-tree portfast
 spanning-tree bpduguard enable
!
...

Bár az STP vállalati hálózati környezetben nagy valószínűséggel továbbra is az alapértelmezett hurokmentesítési mechanizmus marad, a hozzáférési réteg kapcsolói esetén más technológiák is használhatóak, beleértve a következőket:

• Harmadik rétegbeli funkcionalitás kiterjesztése a hozzáférési rétegre is (a hozzáférési rétegbeli- és az elosztási rétegbeli kapcsolók közötti 2. rétegbeli kapcsolatok kiváltása 3. rétegbeli kapcsolatokkal)
• Multi System Link Aggregation (MLAG)
• Shortest Path Bridging (SPB)
• Transparent Interconnect of Lots of Links (TRILL)