STP – A feszítőfa protokoll

Redundancia a hálózatokban

Redundanciára szükség van a hálózatokban, hiszen csak így biztosítható, hogy amennyiben egy útvonal kiesik, egy másik beléphessen automatikusan a helyére. Gondoljunk csak arra, hogy a való életben is élünk ezzel a lehetőséggel: Ha például leáll a metróközlekedés, átszállunk villamosra, és azzal közelítjük meg a célállomásunkat. (Feltéve persze, ha jár arra villamos.) A villamos természetesen nem feltétlenül ugyanazon az útvonalon közlekedik, mint a metró, tehát más állomásokat érintve juttat el a célig. A lényeg, az egyik útvonal kiesése esetén egy másikat használhatunk.

A hálózatokban az útvonalak két szinten jelennek meg, az adatkapcsolati szinten, ahol a keretek, és a hálózati szinten, ahol a csomagok utaznak. A keretek útvonalát a kapcsolók határozzák meg, míg a csomagokét a forgalomirányítók. Ebben a cikkben a kapcsolók közötti redundáns útvonalakról lesz szó.

A redundancia magával hordozza a hurkok kialakulásának veszélyét. Számunkra most a hálózatokban két hurok érdekes, a kapcsolási és az irányítási hurok. A kapcsolási hurkok esetén a kapcsolók között egy szórási tartományban alakul ki a redundáns útvonalak miatt hurok, és ebben a keretek körbe-körbe keringhetnek, míg az irányítási hurok esetén ugyanez a forgalomirányítók között alakul ki, és a csomagok keringhetnek körbe-körbe. (Persze keretbe ágyazva.) Ezt a keringést kell valahogy megakadályoznunk.

Irányítási hurkok esetén ezt statikus forgalomirányítás használatával úgy érjük el, hogy ésszel adjuk ki az útvonalakat létrehozó parancsokat (nem küldjük szándékosan vissza a csomagot egy előző forgalomirányítóhoz). Dinamikus forgalomirányító protokollok használatakor az irányítási algoritmusra bízzuk rá, hogy ne hozzon létre hurkokat. Ez kapcsolatállapot alapú protokollok (pl. OSPF) esetén tiszta sor, hiszen minden forgalomirányító látja a teljes terület topológiáját, így az algoritmus hurokmentes legjobb útvonalat határoz meg. Távolságvektoros protokollok esetén már nem ilyen egyszerű a helyzet (hiszen ott nem rendelkeznek teljes topológiainformációval), ott olyan technikákat kell alkalmazni, mint például a látóhatármegosztás vagy az útvonalmérgezés. Ha mégis hurokba kerülnének a csomagok, akkor pedig IPv4 esetén a fejlécben található TTL mező, IPv6 esetén pedig a Hop Limit mező gondoskodik arról, hogy bizonyos számú továbbítás után a csomag eldobásra kerüljön.

Kapcsolási hurkok esetén ilyen fejléc mezőnk nincsen, vagyis valamilyen más módon kell megszabadulnunk a végtelenül keringő keretektől. És ilyenkor jön az a rossz hír: Ethernet hálózat esetében nincsen ilyen másik mód. Vagyis ha egy keret hurokba kerül, akkor ott elszabadul a pokol, pontosabban szólva a vihar. Ezért csak az az út járható, hogy a hurkot szüntetjük meg. Ilyenkor viszont le kell mondanunk a redundancia adta biztonságról. A megoldás az, hogy a redundanciát nem fizikailag szüntetjük meg (vagyis nem húzzuk ki az UTP kábeleket a kapcsolókból), hanem csupán ideiglenesen lezárjuk azokat a portokat, amelyeken keresztül kialakulhatnak a hurkok. Ha a későbbiekben kiesne egy kapcsolók közötti útvonal, akkor ezen lezárt portok újraengedélyezésével másik útvonal alakítható ki. Ezt a folyamatot végzi Ethernet kapcsolók esetén a feszítőfa protokoll. (Angolul Spanning Tree Protocol, azaz az STP.)

Kapcsolási hurkok hatása a hálózatra

Mielőtt elkezdenénk az STP tárgyalását, nézzük meg, mit okozhat egy 2. rétegbeli hurok. Alapvetően 3 problémával szembesülünk, úgymint az üzenetszórási vihar, az instabil MAC-cím tábla és a duplikált keretek problémája. A következő egyszerű topológiában a három kapcsoló redundáns módon van összekapcsolva, hiszen mindegyik 2-2 útvonalon éri el a másikat.

Az eszközöket most kapcsoltuk fel, így a kapcsolók MAC-cím táblái üresek. Tegyük fel, hogy PC1 küld egy üzenetszórást. (Ez gyakorlatilag az első ARP üzeneténél megvalósul.) SW1 a szórásos keretet minden aktív portján kiküldi (kivéve ahol kapta), vagyis fa0/1 és fa0/2-n. SW2 és SW3 megkapja ezeket a szórásos kereteket, és kiküldik minden aktív portjukon (kivéve ahol kapták), Kövessük nyomon az SW2 felé küldött keretet.  SW2 elküldi PC2 felé, és SW3 felé. SW3 az fa0/3-on keresztül SW2-től kapott szórásos keretet minden aktív portján kiküldi (kivéve ahol kapta), vagyis fa0/2-n is, így az eredetileg SW1-től indult szórásos keret visszajut SW1-ig, mely természetesen minden aktív portján keresztül kiküldi (kivéve ahol kapta), és ez a folyamat ismétlődig megállás nélkül, lassan elfogyasztva a kapcsolók teljes sávszélességét, a kapcsolatok telítődnek, a processzorok túlterhelődnek. A jelenség neve üzenetszórási vihar.

Most képzeljük el azt, hogy PC1 küld egy üzenetet PC2-nek (1). A MAC-cím táblák még mindegyik kapcsolón üresek. Mivel SW1 nem tudja merre található PC2, ezért elküldi a keretet SW2-nek (1A) és SW3-nak (1B), azok pedig tovább küldik (SW2 PC2-nek és SW3-nak, SW3 PC3-nak és SW2-nek), így végeredményben PC2 kétszer kapja meg az üzenetet. Ez a duplikált keretek problémája.

SW3 mit lát, melyik portján érkezett be a PC1-től elindult keret? Először fa0/2-n (1B), vagyis bejegyzi, hogy PC1 MAC címe fa0/2-n keresztül érhető el. Amikor viszont SW2 is elküldi neki a keretet (1A), módosítja a MAC-cím tábláját arra, hogy ezután PC1 fa0/3-on érhető el. Persze a következő alkalommal megint fa0/2-n érkezik be először PC1 kerete (ne is beszéljünk az üzenetszórási viharról…), vagyis ez a bejegyzés (és a többi is) “billeg” a MAC-cím táblában. Ezt hívjuk instabil MAC-cím táblának.

Végeredményben a hálózat használhatatlan. Meg kell szüntetni a hurkot. Vegyük észre: A kapcsolók nem rendelkeznek olyan “kapcsoló táblával”, mint a forgalomirányítók esetén az irányítótábla. Az irányítótábla a forgalomirányítók (illetve a hálózataik) közötti legjobb útvonalakat tartalmazzák. Ezeket a legjobb útvonalakat a forgalomirányító protokollok határozzák meg. Habár az ennek megfelelő “kapcsoló tábla” nincsen, attól még létezhetne egy olyan protokoll, mely a kapcsolók közötti “legjobb útvonalat” határozza meg, a többi útvonalon pedig úgy módosítja a kapcsolók portjait, hogy azokon keresztül ne lehessen kereteket küldeni. Ha bármelyik ilyen legjobb útvonal kiesik, akkor persze keres egy másikat. Ez a protokoll lesz az STP protokoll, melyben a feladatokat az STA (Spanning Tree Algorithm) algoritmus látja el. Először az IEEE 802.1D szabványban jelent meg. Azóta számos, szabadon felhasználható és céges verziója is megvalósult. A Cisco kapcsolók alapértelmezetten futtatják az STP protokoll-t. (Illetve az annak megfelelő Cisco megvalósítást, a PVST+ protokollt.)

Az STP protokoll működési elve, a BPDU-k

Mielőtt nekilátnánk az STP protokoll tárgyalásának, el kell mondani, hogy az eredeti STP protokoll (802.1d) még nem tudott VLAN-onként különbözőképpen működni, a Cisco ezért kidolgozta a PVST+ protokollt, mely minden VLAN-on az STP egy-egy példányát képes futtatni. A Cisco viszont nem teljesen az STP-t ültette át a saját rendszerébe, például a portok szerepeinél az RSTP szerepeket használja már. (A későbbiekben természetesen ezeket a fogalmakat tisztázzuk.) Az írás célja az STP és különböző verzióinak a bemutatása, de a bemutatott példák Cisco kapcsolókon kerültek konfigurálásra, így ott néha (főleg ha valaki maga próbálja ki azokat) nem a klasszikus STP jelenik meg. Az írás végére remélem minden világos lesz.

Az STP protokoll feladatát úgy is megfogalmazhatjuk, hogy egy redundáns kapcsolatokat tartalmazó 2. rétegbeli hálózatban a kapcsolók portjainak állapotát úgy módosítja, hogy minden kapcsoló minden másikat egy és csak egy útvonalon érje el. A protokoll ezeknek az útvonalaknak a meghatározásához először minden portot lezár, majd meghatározza azokat a portokat, amelyeket továbbító állapotba kell kapcsolni. Első lépésben kijelöl egy központi, úgynevezett gyökérponti hidat (root bridge), és úgy módosítja a hálózatban található kapcsolók portjainak az állapotát, hogy a többi kapcsoló ezt a gyökérponti hidat érje el  egyetlen, legjobb útvonalon. (A gyökérponti kapcsolót úgy kell elképzelnünk, mintha ez ülne a hálózat csúcsán, vagy mintha egy fának ő lenne a gyökere. Nézőpont kérdése.) Így akadályozzák meg a hurkok kialakulását. Ha egy ilyen legjobb útvonal kiesik, a portok állapotának változtatásával új útvonalat jelöl ki, ügyelve arra, hogy ilyenkor se alakuljon ki hurok. A kapcsolók ennek a folyamatnak a vezérlésére üzeneteket váltanak egymással. Ezek nevezzük BPDU (Bridge Port Data Unit) üzeneteknek. A BPDU üzeneteknek két fajtája van, a konfigurációs BPDU-k (ennek a leggyakrabban használt fajtája a Hello BPDU) és a topológiaváltozást leíró BPDU-k (ezek a TCN BPDU-k, vagyis topology change notification BPDU). Egy konvergált hálózatban a konfigurációs (Hello) BPDU-kat a gyökérponti kapcsoló küldi a többi kapcsolónak (az eredeti STP-ben), míg a topológiaváltozást leíró BPDU-kat minden kapcsoló képes küldeni, ha valamilyen változást érzékel a hálózatban. (A hálózat felkapcsolás után, amíg meg nem választják a gyökérponti hidat, illetve a topológiaváltozás kezelése közben minden kapcsoló küldhet konfigurációs BPDU-t) A portok csak az adatforgalom elől kerülnek lezárásra, a BPDU-kat a lezárt portokon keresztül is küldik a kapcsolók, ezzel biztosítva azt, hogy folyamatosan nyomon tudják kísérni a hálózat állapotát, és reagálni tudjanak az egyes változásokra. (Ez nagyon szépen mutatja a hálózatokban a vezérlési sík (control-plane) és az adatsík (data-plane) közötti különbséget. A vezérlési síkon továbbítódnak a BPDU-k, az adatsíkon pedig a felhasználói adatok. A portok csupán az adatsíkon kerülnek lezárásra, vezérlési síkon a BPDU-k számára nyitottak maradnak. (Ha az autópályán egy baleset miatt lezárják az egyik felhajtót, attól még a mentők felhajthatnak rajta…)

A kapcsolók azonosítása, a BID

A kapcsolókat az STP protokoll a BID (BridgeID) értékükkel azonosítja. A BID érték két részből tevődik össze: a kapcsoló prioritásából és a kapcsoló MAC címéből. A prioritás alapértelmezett értéke VLAN-onként különböző: 32768+VLAN száma. (A VLAN számát kiterjesztett rendszer azonosítónak, extended system ID-nak is nevezzük.) Vagyis VLAN1 alapértelmezett prioritása: 32768+1 (=32769), VLAN 15 prioritása: 32768+15 (=32783) Itt van egy kis zavar, hogy mit is értünk prioritáson? Beletartozik a VLAN értéke, vagy nem? A válasz az, hogy amennyiben konfiguráljuk a prioritást, akkor a VLAN száma nélkül adjuk meg, viszont ha dolgozunk vele, vagy lekérdezzük, akkor már beleszámít a VLAN értéke is. (Ennek a látszólagos következetlenségnek az az oka, hogy az STP első változatában még nem volt része a prioritásnak az adott VLAN száma.) A prioritás VLAN-onként állatható a spanning-tree vlan x priority paranccsal, de csak 4096-os lépésekben. (Hogy miért, azt a későbbiekben fogjuk látni.) Kérdezzük le a parancs help-jét:

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

Próbáljunk beállítani egy nem megengedett prioritást. (Vagyis nem 4096 egész többszörösét.) Az IOS a hibajelzés mellett kiírja a használható értékeket, így innen kiválaszthatjuk a megfelelőt, nem kell számolgatnunk.

SW1(config)#spanning-tree vlan 1 priority 10
% Bridge Priority must be in increments of 4096.
% Allowed values are:
0 4096 8192 12288 16384 20480 24576 28672
32768 36864 40960 45056 49152 53248 57344 61440

Mivel a BID értékében szerepel a VLAN száma, ezért minden VLAN-ban a kapcsolónak más és más lehet a BID értéke. Ennek jelentőségét a későbbiekben még látni fogjuk. (Mivel az eredeti STP-ben még nem volt a prioritás része a VLAN száma, a protokoll még nem tudta megkülönböztetni a kapcsolókat a különböző VLAN-okban, vagyis mindegyik VLAN-ban ugyanaz volt a BID értéke. Ennek az volt az eredménye, hogy minden VLAN-ban ugyanaz a feszítőfa alakult ki, vagyis egy port vagy minden VLAN forgalmát átengedte, vagy minden VLAN forgalmát tiltotta.)

Készítsünk egy egyszerű hálózatot: Legyen benne egyetlen kapcsoló, amelyben 3 VLAN-t hozunk létre (az alapértelmezett VLAN1-en kívül). Legyenek ezek a 10-es, 20-as és 30-as VLAN-ok, és rendeljünk hozzájuk egy-egy portot. Kérdezzük le az STP állapotát:

SW1#sh spanning-tree
No spanning tree instance exists.

Vonjuk le a következtetést: Habár az STP alapértelmezetten mindig engedélyezve van a  Cisco kapcsolókon, de  ha a kapcsolónak nincsen aktív (felkapcsolódott) portja egy VLAN-ban, akkor ott nem fog futni a protokoll egyetlen példánya sem. Most kapcsoljunk a portokhoz egy-egy PC-t.

Kérdezzük le az STP állapotát (a parancs kimenetéből csak a számunkra érdekes részeket emeltem ki):

SW1#sh spanning-tree
VLAN0010
…
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 0000.0CD8.866B
…
VLAN0020
…
Bridge ID Priority 32788 (priority 32768 sys-id-ext 20)
Address 0000.0CD8.866B
…
VLAN0030
Bridge ID Priority 32798 (priority 32768 sys-id-ext 30)
Address 0000.0CD8.866B
…

Jól látható, hogy mindegyik VLAN-ban a fentiekben elmondottak szerint alakult a prioritás és a BID értéke. Mindegyik VLAN-ban a kapcsoló MAC címe természetesen azonos, hisz az a kapcsolóhoz, és nem a VLAN-hoz tartozik.

A következőkben az egyszerűség kedvéért csak egyetlen VLAN-ban fogunk dolgozni, de már tudjuk, mindegyik VLAN-ban az STP egy-egy példánya fut majd a Cisco kapcsolókon.

Nézzük meg, miért is ilyen furcsa mód, 4096-os lépésekben kell állítani a prioritást. Ehhez a BPDU üzenetek felépítésének ismeretére van szükségünk. Kezdetekben, amikor az STP még nem tudott különböző VLAN-okban különböző példányokban futni (pl. IEEE802.1Q), a BPDU üzenet fejlécében a BID mezőnek két része volt, a prioritás és a MAC cím. A prioritás 2 byte-ot foglalt le, a MAC cím 6 byte-ot, így a prioritást tetszőleges értékre, 0-65535-ig tudtuk beállítani. A későbbi STP verziókban, ahol már VLAN-onként is különböző prioritást lehetett beállítani, beemelték a BID mezőbe a VLAN számát is, mégpedig az addigi prioritás rész 2 byte-jának alsó 12 bitjébe. (Emlékezzünk vissza, a VLAN-ok száma 12 biten van ábrázolva.) Így a prioritásra a felső 4 bit maradt, ez összesen 16 kombinációt jelent (2⁴=16), és mivel a 12. bittől kezdve van tárolva, minden egyes növeléssel 2¹²=4096 nő meg az értéke. (Olyan ez, mintha a fizetésünket nem 1Ft-tal tudnák emelni, hanem csak 1000Ft-os lépésekben.) Amikor beállítjuk a prioritást, akkor ennek a 4 bitnek az értékét adjuk meg a 2 byte-on belül helyiértékhelyesen, amikor lekérdezzük, akkor viszont a VLAN számával kiegészítve kapjuk meg.

A gyökérponti híd megválasztása (gyökérponti kapcsoló)

Ahogyan korábban már olvastuk, az STP protokoll olyan topológiát alakít ki a szórási tartományon belül, melyben minden kapcsolót egy és csak egy útvonal köt össze. (Ezt ahogy láttuk a Cisco kapcsolókban megvalósított változata minden VLAN-ban külön-külön megteszi, de ezt a továbbiakban már nem írom le külön.) Ehhez első lépésben a kapcsolók közül kiválaszt egyet, melyet elnevez gyökérponti hídnak. (Angolul ez lesz a root bridge.) Minden más kapcsoló majd ezt a gyökérponti hidat fogja elérni a legkisebb költségű útvonalon. A választás elve nagyon egyszerű: az a kapcsoló lesz a gyökérponti híd, amelynek legkisebb a BID értéke. Mivel a BID érték a prioritásból és a MAC címből áll össze, és előll áll a prioritás, a gyökérponti híd a legkisebb prioritású lesz. Amennyiben azonos a prioritások értéke, akkor a kisebb MAC címűt veszi. (Mivel az adott VLAN-ban mindenkinek a prioritása 32768+VLAN lesz, gyakorlatilag véletlenszerű a gyökérponti híd kiválasztása, hiszen nem szoktuk a kapcsolókat MAC cím alapján sorba rendezni.)

Hogyan történik ez a választás? Miután felkapcsolódtak a kapcsolók (tegyük fel, hogy most ez egyszerre történik), minden kapcsoló elkezdi hirdetni magáról BPDU üzenetekben a saját BID értékét, és azt, hogy szerinte melyik kapcsoló a gyökérponti híd. (Ennek is a BID-jét küldik el.) Először saját magukat jelölik ki erre a szerepre, hiszen senki mást nem ismernek, de ha fogadnak egy olyan BPDU-t, amelyben a BID érték kisebb, mint az általuk addig ismert gyökérponti híd BID-je, akkor már ezt a kisebbet fogják hirdetni. Egy kapcsoló szempontjából superior BPDU-nak nevezünk minden olyan BPDU-t, amelyikben jobb (azaz kisebb) BID értékű gyökérponti híd van hirdetve, mint amiről a fogadó kapcsoló tud. Minden más BPDU-t inferior BPDU-nak nevezünk. (Valójában ennél bonyolultabb a superior BPDU kiválasztásának folyamata, erről az STP védelmi mechanizmusok írásban lehet olvasni.)

Ez a választás körülbelül úgy zajlik le, mintha egy osztályban szeretnénk megtalálni a legrövidebb nevű tanulót. Minden tanuló elmondja a vele kapcsolatban állóknak a saját nevét, és azt, hogy szerinte kié a legrövidebb név. Először a sajátjukét mondják, de ha valakitől hallanak egy rövidebbet, onnantól kezdve már azt mondják tovább.

A folyamat végére a szórási tartományban minden kapcsoló tisztában lesz azzal, hogy ki lett gyökérponti hídnak megválasztva. Ezt le is kérdezhetjük kapcsolónként és VLAN-onként.

Induljunk ki az előző topológiából ismét, ahol a VLAN1-hez kapcsolódnak a PC-k. Hagyjuk a BID értéküket alapértelmezetten, vagyis a MAC címük alapján dől el, melyik lesz a gyökérponti híd. Adjuk ki kapcsolónként ismét a sh spanning-tree parancsot. (Ismét csak a számunkra érdekes sorait értelmezzük.)

SW1#sh spanning-tree
VLAN0001
…
Root ID Priority 32769
Address 000A.4187.DA32
…
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0060.2F95.25C8

SW2#sh spanning-tree
VLAN0001
…
Root ID Priority 32769
Address 000A.4187.DA32
This bridge is the root
…
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000A.4187.DA32

SW3#sh spanning-tree
VLAN0001
…
Root ID Priority 32769
Address 000A.4187.DA32
…
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0060.3E19.E6D0

A parancsok kimenetéből látható, hogy minden kapcsoló rendelkezik azzal az információval, hogy melyik kapcsolót tekinti gyökérponti hídnak. Ezt írja ki először, alatta látható a saját MAC címe. Az a kapcsoló a gyökérponti híd, amelyiknél a híd MAC címe és a saját MAC címe megegyezik. Jelen esetben ez az SW2, mivel neki van a legkisebb MAC címe. Ennél a This bridge is the root szöveg is megjelenik.

Növeljük meg most SW2 prioritását 4096-tal (32768+4096=36864), majd kérdezzük le ismét, ki lett az gyökérponti híd. SW2 kiesik a versenyből. SW1-nek és SW3-nak kisebb, de egyenlő a prioritása, közöttük ismét a MAC cím dönt, és mivel SW1-nek kisebb a MAC címe, SW1 nyeri a választást:

SW2(config)#spanning-tree vlan 1 priority 36864

SW1#sh spanning-tree
VLAN0001
…
Root ID Priority 32769
Address 0060.2F95.25C8
This bridge is the root
…
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0060.2F95.25C8

A gyökérponti híd mellett megtörténik egy tartalék gyökérponti híd megválasztása is, mely abban az esetben lép az első helyébe, ha az kiesik. (A tartalék az, amelyik a második legkisebb.) Ebben az összefüggésben beszélhetünk elsődleges (primary root bridge) és másodlagos (secondary root bridge) gyökérponti hídról.

Mint láttuk, a prioritást 4096-os lépésekben lehet beállítani, és az is gondot okoz, hogy amikor egy kapcsolón (illetve egy VLAN-ján) ezt megtesszük, nem tudhatjuk közben, hogy a többi kapcsolón milyen értékű. Szerencsére van két parancsunk, amellyel a prioritások ismerete nélkül be tudjuk állítani, hogy melyik kapcsoló legyen az adott VLAN-ban az elsődleges és a másodlagos gyökérponti híd:

SW1(config)#spanning-tree vlan 1 root primary

SW2(config)#spanning-tree vlan 1 root secondary

Egy konvergált (tehát minden változásra már reagált) hálózatban a gyökérponti hídnak kiemelt szerepe van, hiszen ez a kapcsoló küld ki folyamatosan konfigurációs Hello BPDU üzeneteket. Ezeket az üzeneteket minden más kapcsoló csak egyetlen portján fogadhatja (ezeket fogjuk gyökérponti portnak hívni), hiszen ez jelenti, hogy a gyökérponti hídhoz csak egyetlen útvonalon kapcsolódik.

Portok költségei, útvonalak költségei

Az STP protokoll feladata, hogy úgy módosítsa az egyes kapcsolók portjainak állapotát, hogy minden kapcsolók a gyökérponti hidat egy és csak egy útvonalon érje el, és ez az útvonal a legjobb költségű legyen. Hogyan számolja a protokoll  az útvonalak költségét? A portok költségéből. Az STP alapértelmezetten a következő táblázatban látható költségeket rendeli a különböző sebességű portokhoz. (Meg kell jegyezni, hogy ezeket az értékeket az eredeti 802.1D protokoll definiálta, és azóta már – noha ezeket tartották meg alapértelmezett értéknek – más tartományokat ajánl. Ezeknek a Interneten utána lehet járni. )

Egy port STP költsége a show spanning-tree parancs kimenetén leolvasható (ismét csak a parancs kimenetének számunkra lényeges részét emeljük ki.) Egy kapcsolón, ahol egy 100Mbps és egy 1Gbps portot is használunk, a fenti táblázatnak megfelelő költségek jelennek meg. (A többi adat jelentését a későbbiekben tisztázzuk még.)

SW1#sh spanning-tree
VLAN0001
…
Interface        Role Sts Cost      Prio.Nbr Type
Fa0/1            Desg LSN 19        128.1    P2p
Gi0/1            Root FWD 4         128.25   P2p

Amennyiben átállítjuk bármelyik port sebességét a speed paranccsal, annak STP költsége is meg fog változni. Mint látjuk, a portok költségét alapértelmezetten a port sebessége határozza meg, de lehetőségünk van  manuálisan beállítani VLAN-onként a port STP költségét a spanning-tree cost paranccsal. Módosítsuk például VLAN1-ben a G0/1 port STP költségét:

SW1(config)#int g0/1
SW1(config-if)#spanning-tree vlan 1 cost 10

Egy útvonal költsége ezek után nem más, mint az útvonalon található kimenő portok költségeinek összege. (Később ezt még pontosítani fogjuk.)

A legjobb útvonalak meghatározása, a gyökérponti port

A legjobb útvonalak meghatározása a gyökérponti kapcsoló megválasztása után kezdődik el. A gyökérponti kapcsoló minden portján elkezd hirdetni konfigurációs BPDU-kat. A többi kapcsoló fogadva ezeket az üzeneteket, frissítik a megfelelő mezőket benne, majd tovább küldik a portjaikon. (Azokon persze nem, amelyiken fogadták.) A nem gyökérponti híd kapcsolók tehát saját maguk nem generálnak konfigurációs BPDU-kat, csak továbbítják a kapottakat. Amennyiben egy kapcsoló két portján is fogad konfigurációs BPDU-t, az azt jelenti számára, hogy a gyökérponti kapcsolót több útvonalon is eléri, vagyis a hálózatban hurok van. Ezek közül csak az egyiket fogja használni. De melyiket? Természetesen a legkisebb költségűt. De hogyan határozza meg, melyik az?

Vizsgáljuk meg a lenti topológiát. Tegyük fel, hogy a kapcsolók prioritásai úgy vannak beállítva, hogy SW1 nyerte el a gyökérponti híd szerepét, így ez a kapcsoló kezdi el küldeni a konfigurációs BPDU-kat. SW2 a g0/1-es portján, míg SW3 a g0/2-es portján fogadja azokat. Mivel SW2 és SW3 csak egyetlen úton éri el SW1-et, így kimondhatjuk, ezeken a portokon keresztül érik el a legkisebb költséggel a gyökérponti hidat. Ezek a portok kitüntetett szerepet játszanak, ezeket nevezzük gyökérponti portoknak (routed port, RP). Gyökérponti portoknak nevezzük a kapcsolók azon portjait, amelyeken keresztül a legkisebb költséggel elérik a gyökérponti hidat. A kapcsolók a gyökérponti portjaikon fogadják a gyökérponti hídtól érkező konfigurációs BPDU-kat.  Értelemszerűen minden kapcsolónak csak egyetlen gyökérponti portja lehet. (Hiszen ha több lenne, akkor több útvonalon is elérné a gyökérponti hidat, ez viszont hurok jelenlétét feltételezné a hálózatban.)

A legjobb útvonal meghatározásának az az elve tehát, hogy a gyökérponti híd konfigurációs BPDU-kat küld minden aktív portján (g0/1 és g0/2), melyben azonosítja magát (BID_SW1), és azt, hogy milyen költséggel lehet a gyökérponti hidat elérni. Vizsgáljuk meg most SW2 szemszögéből ezt a hálózatot. SW2 egyrészt ezt a BPDU-t megkapja közvetlenül SW1-től (1-es út), illetve megkapja SW3-on és SW4-en keresztül is (2-es út). Az 1-es útvonalon kapott BPDU-ban szereplő költséghez (0) hozzáadja a fogadó portjának költségét (4), így megállapítja, hogy az 1-es útvonalon 4-es költséggel éri el a gyökérponti hidat. A 2-es útvonalon már jobban módosul a 0-s költségű BPDU. Először is SW3 fogadja,  a költséghez hozzáadja a bejövő port költségét (4), módosítja a küldő BID értékét a sajátjára (BID_SW3), majd kiküldi a g0/1 portján. Ezt megkapja SW4, és végrehajtja rajta ugyanezeket a módosításokat, vagyis a költséghez hozzáadja a saját bejövő portjának (g0/1) költségét (4), így a teljes útvonal költsége már 8, és módosítja a küldő BID értékét BID_SW4-re. SW4 ezután továbbküldi a BPDU-t fa0/24-en (persze fa0/23-on is, de most az SW1-et vizsgáljuk). SW1 miután megkapja fa0/24-en keresztül, megnöveli az útvonal költségét a port költségével (19), így SW1 számára ez a 2-es útvonal teljes költsége 27 lesz. Vagyis SW1 két útvonalat lát a gyökérponti híd fel: Az egyik SW1-en keresztül 4-es költséggel, a másik SW4-en keresztül 27-es költséggel halad. Természetesen a kisebb költségűt választja, tehát a g0/1-es portján keresztül éri el a legkisebb költséggel a gyökérponti hidat. Így ez a g0/1 portja lesz a gyökérponti port. Így leírva lényegesen bonyolultabbnak tűnik, mint amilyen valójában.


<
A többi ábrán ugyanígy a többi kapcsoló szempontjából látható a legjobb útvonal választás. SW3 számára a g0/2 portja a gyökérponti port (4-es útvonalköltséggel), SW4 számára a g0/1-es port a gyökérponti port (8-as útvonalköltséggel) és SW5 számára az fa0/23 port a gyökérponti port (27-es útvonalköltséggel).

Nagyon lényeges az egyes útvonalakon a nyilak iránya. Habár azt mondjuk, hogy az egyes kapcsolók ezeken keresztül érik el a gyökérponti hidat, de mint látjuk az útvonalak meghatározásának iránya fordított, hiszen a gyökérponti hídtól küldött BPDU üzenetekből lett meghatározva a legjobb út.

Mi van akkor, ha két azonos költségű útvonal is vezet a gyökérponti hídhoz? Tegyük fel, hogy SW3 és SW4 között is egy 100Mbps-es 19-es STP költségű kapcsolat van. Ilyenkor már szükségünk van a BPDU-kat küldő kapcsolók BID értékére is. (A topológián a prioritásokból lehet látni, hogy BID_SW2<BID_SW3). A szabály az, hogy amennyiben egy kapcsolóból két azonos költségű legjobb útvonal is halad a gyökérponti híd felé, akkor a kisebb BID-értékű kapcsoló felé vezető útvonalat választja az STP. (Vagyis itt az SW2 felé haladó fa0/24 port lesz a gyökérponti port.) Ezt úgy is mondhatjuk, hogy a kisebb BID értékű BPDU-t küldő kapcsoló felé vezető útvonalat kell választani. (Ebből is látszik, hogy nem úgy kell gondolkodni, hogy az adatforgalom halad a gyökérponti híd felé, hanem a gyökérponti hídtól származó BPDU-k útját kell nyomon követni. Vezérlési sík forgalma!)

És mi van akkor, ugyanaz a kapcsoló küldi mindkét legjobb útvonalról a BPDU üzenetet? Ez akkor fordulhat elő, ha két kapcsoló között 2 vagy több link is ki van alakítva. Ennek a helyzetnek a megoldására be kell vezetnünk a port STP prioritásának a fogalmát. A port STP prioritása egy 0 és 240 közötti érték (alapértelmezett értéke 128), mely 16-os lépésekben állítható), és a szabály az, hogy amennyiben egy kapcsolón 2 vagy több legjobb útvonal is vezet, akkor a legkisebb STP prioritású port lesz kiválasztva. Ha a portoknak azonos a prioritása, akkor a legkisebb sorszámú port lesz kiválasztva. (Az ábrán most csak a legjobb útvonal látható, de természetesen SW5 mindkét portja megkapja mindegyik útvonalról a BPDU-kat.)

A port prioritást a spanning-tree port-priority paranccsal állíthatjuk be új értékre VLAN-onként. (Ne feledjük, 16-os lépésekben!)

SW5(config)#int fa0/23
SW5(config-if)#spanning-tree vlan 1 port-priority 112

A port STP prioritás értéke is megjelenik a sh spanning-tree parancs kimenetén. Például az SW2 kapcsolón kiadva:

SW5#sh spanning-tree
VLAN0001
…
Interface        Role Sts Cost      Prio.Nbr Type
Fa0/24           Desg FWD 19        128.24   P2p
Gi0/1            Root FWD 4         128.25   P2p

Felmerülhet a kérdés, hogy miért pont 16-os lépésekben lehet állítani a port STP prioritását. A válasz ugyanaz, mint a BID-nél volt. Minden port rendelkezik egy port ID-val, mely két részből áll: A port prioritásból (alapértelmezetten 0), és a port sorszámából. A Port ID 2 byte hosszú, a felső 4 bitjén van a prioritás, az alsó 12 biten a portszám. A felső 4 biten meg ugye 16-osával lehet lépkedni. (Az egy kis következetlenség, hogy habár a kapcsolók BID értékében a prioritás szintén a 2. byte felső 4 bitjén van ábrázolva, és ott 4096-osával lépkedünk, itt meg 16-osával. A BID-nél 2 byte-on, míg a PID-nél 1 byte-on kell helyiértékhelyesen megadni a prioritást. De legalább a port azonosítónál nem kell a port számát is bevenni a prioritásba.)

Ahogyan láttuk, a gyökérponti híd által küldött BPDU-kat a kapcsolók tovább küldik a megfelelő módosítás után. A BPDU-ban van egy érték (a message age), mely az üzenet korát jelöli. A gyökérponti híd ezt 0-ra állítja, SW2 és SW3 ezt 1-gyel megnöveli (értéke így 1 lesz). SW4 már ezzel az 1-es értékkel kapja meg, ez is megnöveli 1-gyel (értéke így 2 lesz), továbbküldi SW5-nek, amely tehát 2 értékkel kapja meg. (Úgy működik tehát, mint egy fordított TTL az IPv4 fejlécében.) Lényegében tehát a message age azt jelenti, hogy az adott kapcsoló milyen messze van a gyökérponti hídtól. Maximális értéke 19, vagyis a 20. kapcsoló még elfogadja, de amikor megnöveli 1-gyel (20-ra) és továbbküldi, a 21. kapcsoló már eldobja a BPDU-t. Vagyis az STP elméletileg maximum 20 szinten elhelyezkedő kapcsolók között működik. (Ilyenkor a legfelső szintre a gyökérponti hidat képzeljük.) Gyakorlatilag ez az érték stabil STP kapcsolat kialakításánál kisebb. Miért? Erre a választ legalább megközelítőleg az STP időzítőinek tárgyalásánál adjuk meg.

Kijelölt portok (Designated ports)

Ahogyan korábban olvashattuk, az STP induláskor a kapcsolók mindegyik aktív portját blokkolja, vagyis az adatforgalmat nem engedi át rajtuk, kizárólag a BPDU-kat. A protokoll végeredményben meghatározza azokat a portokat, amelyeket továbbító állapotba kapcsolva kialakulnak a hurokmentes legjobb útvonalak. A gyökérponti portok ezek közé a továbbító állapotba kapcsolt portok közé fognak tartozni. Ez azonban még nem elegendő, így a következő lépésben meghatározza az úgynevezett kijelölt portokat (designated ports, DP). A kijelölt portok azok a nem gyökérponti portok, melyek a feszítőfában továbbító állapotba kerülnek. Az első szabály, hogy minden gyökérponti portot tartalmaz link másik végén kijelölt port található. (Ez természetes, hiszen a gyökérponti portokról érhető el a gyökérponti híd a legkisebb költséggel, vagyis az ezekből kiinduló adatkereteknek továbbításra kell kerülniük, ez pedig csak akkor lehet, ha a link másik vége nincsen lezárva.) A következő ábrán ezek a kijelölt portok kerülnek feltüntetésre (kék színnel):

Megnézve a topológiát az SW2 és SW4 közötti linken sem kijelölt, sem gyökérponti port nem került meghatározásra. Kijelölt portot viszont minden linknek kell tartalmaznia, így ebből a szegmensből is meg kell határozni azt az útvonalat, amelyen legkisebb költséggel elérhető a gyökérponti híd. (Mondhatnánk, hogy miért kell ezt megtenni, hiszen egy linken nincsen egyetlen olyan eszköz sem, amely adatforgalmat tudna generálni. Ebben a topológiában nincsen, de ha elképzeljük, hogy SW2 és SW4 között egy HUB található, akkor a HUB-hoz kapcsolt gépek már küldhetnek adatokat a hálózatba. A HUB-on nem fut az STP, így a kapcsolóknak kell meghatározni, hogy melyik portjukon engedik ki a szegmensből származó adatkereteket.) Itt is meg kell határoznunk egy kijelölt portot. Ennek érdekében képzeljünk el egy hosztot a link közepén, és nézzük meg, melyik irányban éri el kisebb költséggel a gyökérponti hidat. (Persze itt is fordítva működik a dolog, a gyökérponti hídtól származó BPDU-k jutnak el a szegmensbe.) Jól látható, hogy az SW2-n haladó útvonal a kisebb költségű, így SW2 fa0/24 portja lesz a kijelölt port, ez is továbbító állapotba lesz kapcsolva. A szegmens maradék portja blokkolt port (blocked port, BP) lesz, és az adatforgalom elől lezárásra kerül. Készen is vagyunk, gyakorlatilag ennek az egy portnak a lezárása szüntette meg a redundanciát a hálózatban. (Amíg az gyökérponti port és a kijelölt port az STP két port szerepe, addig a blokkolt port itt csak az értelmezhetőség kedvéért lett bevezetve, ilyen szerepet nem definiál az STP.)

Port szerepek meghatározása – összefoglalás

Foglaljuk most össze azokat a lépéseket, amelyeket az STP végigjár, míg meghatározza a port szerepeket:

1. A gyökérponti híd kiválasztása a minimális BID érték alapján.
2. A gyökérponti híd minden portja kijelölt port lesz (DP).
3.  Minden nem gyökérponti kapcsolón egy és csak egy gyökérponti port (RP) választása. Ezekről érhető el a legolcsóbb úton a gyökérponti híd. Ha több azonos költségű útvonalat is található, akkor a kisebb BID értékű kapcsoló felé vezető utat választja. Ha ugyanaz a kapcsolóból indulna ki a két (vagy több) azonos költségű út, akkor a kisebb STP port prioritásút választja. Ha az is azonos lenne, akkor a kisebb portszámút.
4. A gyökérponti portokkal minden szemben lévő port kijelölt port lesz (DP). Ez azért van, mert ha RP-ből indul ki a legkisebb költségű út, akkor kell, hogy ki is tudjanak menni a szegmensből a keretek, tehát a szemben lévő portok nyitva kell legyenek.
5. Most azokat a kapcsolatokat (szegmenseket) veszi, amelyekben se DP, se RP nincsen, tehát érintetlenek. Meg kell határozni, hogy melyikből merre vezet a kisebb költségű út a gyökérponti hídhoz. Képzeljünk el a szegmensben egy gépet (Ha ott HUB lenne, bele is rakhatnánk), és az hogyan éri el a gyökérponti hidat. Ugyanúgy kell számolni, mint a 3-as pontban.
6. A gyökérponti és kijelölt portokat továbbító módba kapcsolja, minden más port blokkolt állapotú lesz.

Port szerepek, port állapotok, az STP időzítői

Mint korábban láttuk tehát, az STP protokoll a kapcsolók portjai között két szerepet oszt ki, a gyökérponti és a kijelölt port szerepeket.

(STP protokoll azokkal a portokkal nem foglalkozik, amelyek vagy adminisztratív módon, vagy a működésükből adódóan le vannak kapcsolva. Ezeket letiltott állapotúaknak (disabled state) tekinti.)  A gyökérponti és kijelölt portokat  továbbító állapotba (forwarding state) fogja kapcsolni. Ez azonban nem megy egyik pillanatról a másikra. Gondoljuk csak végig, a kapcsolók MAC cím táblája még a régi állapotot tükrözi, vagyis olyan portokat is használhat a MAC cím tábla szerint az adatkeretek továbbítására, amelyek az új feszítőfában már lezárt állapotba kerülnek. Ezek a hibás bejegyzések átmeneti hurkokat okozhatnának. Egyszerű lenne minden kapcsoló MAC cím tábláját kitörölni, de akkor rengeteg elárasztás történne a szórási tartományban. Az STP ezért először lezárt állapotból figyelő állapotba (listening state) kapcsolja a portokat.  Ebben az állapotban a porton keresztül fogadja a BPDU üzeneteket, a felhasználói adatkereteket nem továbbítja, de figyeli azokat.  A figyelő állapot után átkapcsol a tanuló állapotba (learning state), ahol még mindig nem továbbítja a beérkező adatkereteket, de a forrás MAC címük alapján elkezdi frissíteni a MAC cím táblát, vagyis az elavult bejegyzések frissülhetnek.  Míg a tanuló állapot feladata érthető, a figyelő állapot feladata további magyarázatot igényelhetne. Mit jelent az, hogy figyeli? Mit figyel? Egyes tankönyvek azt írják, hogy ilyenkor a MAC cím táblából kiöregedhetnek a nem használt MAC címek. Ez azért nem lehet teljesen igaz, mert a Cisco kapcsolók MAC cím táblájának bejegyzései alapértelmezetten 300 másodperc alatt öregszenek ki, a figyelő állapot meg messze nem tart eddig. (Későb bazért látni fogjuk, hogy az STP aktívan tesz azért, hogy az elavult MAC címek kikerüljenek mihamarabb a MAC cím táblából.) Érdekes tudománytörténeti feljegyzés, amit az STP protokoll megalkotója Radia Pelman írt az egyik könyvében. Eszerint amikor kifejlesztette a protokollt, és a szabványügyi bizottság előtt bemutatta, akkor ő csupán egyetlen átmeneti állapotot tervezett (ezt ő preforwarding állapotnak nevezte), de a bizottság ezt két állapotra bontotta: a figyelő és a tanuló állapotra. Pelman szerint erre nem lett volna szükség, csak bonyolultabbá tette a protokoll megértését, a bizottság szerint viszont így a jobb. Így szólhatnak bele a bizottságok a tudósok munkájába. Amikor megalkották az STP gyors változatát, akkor ezt a figyelő állapotot kihagyták… Radia Pelman elégedetten dőlhet hátra a karosszékében (ezen cikk írásakor 71 évesen Amerikában)…

A következő táblázat a fenti STP állapotokat mutatja be összefoglalva:

Mennyi időt szán az STP a különböző állapotokra? Ezeket határozzák meg az STP időzítői. A figyelő és a tanuló állapot idejét a forward timer határozza meg, melynek alapértelmezett értéke 15 másodperc. Ez az érték a spanning-tree forward-time paranccsal állítható VLAN-onként 4 és 30 másodperc között. A kapcsoló tehát alapértelmezetten 15 másodpercet vár a figyelő állapotban, és még 15 másodpercet vár a tanuló állapotban is. (Régen, a lassú Ethernet hálózatokban ez az időtartam még elfogadható volt, ma már túl hosszú lenne!)

A második időzítőnk az max age timer, mely azt határozza meg, hogy egy kapcsoló mennyi időt várjon topológiaváltozáskor, míg elkezdi felépíteni az új feszítőfát. Alapértelmezett értéke 20 másodperc, és ez a  spanning-tree max-age paranccsal változtatható meg szintén VLAN-onként 6 és 40 másodperc közötti értékre. Ennyi idő alatt kell eljutni a gyökérponti hídtól a legtávolabbi kapcsolóig egy Hello BPDU-nak.  Amikor egy kapcsolónak a gyökérponti portján (csak itt kaphat ugye) beérkezik egy Hello BPDU (a gyökérponti híd küldte), akkor a max age időzítőjének értékétől elkezd visszaszámolni. Ha eléri a 0-t, akkor elkezdi a feszítőfa újraépítését. Persze ha közben befut egy másik Hello BPDU, akkor újrakezdi a visszaszámolást. Ezért a max age időtartamot úgy is felfoghatjuk, hogy a beérkezett Hello BPDU-nak ez az érvényességi ideje.

A harmadik időzítőnk a Hello-timer, amely 2 másodperces alapértelmezett értékkel azt szabályozza, hogy a gyökérponti híd hány másodpercenként küldjön Hello (konfigurációs) BPDU-kat a kijelölt portjain egy konvergált hálózatban. Konfigurálni a spanning-tree hello-time paranccsal lehet VLAN-onkét 1-10 másodperc között. Ha egy kapcsoló ennyi időnként nem kapja meg a Hello BPDU-t, akkor a max age timer által megadott ideig még vár, és utána elkezdi újra felépíteni a feszítőfát. (Persze ha max age alatt mégis kap egyet, akkor nincs változtatás.)

Meg kell jegyezni, hogy a protokoll dokumentációja ezen 3 időzítőn kívül még számos másikat is definiál (úgymint például a BPDU transmission delay-t, mely azt határozza meg, hogy mennyi idő teljen el egy konfigurációs BPDU fogadása és továbbküldése között – 1 másodperc az ajánlott érték -, de ezekkel most nem foglalkozunk bővebben.) Mivel az időzítők értéke egymást befolyásolja, nem illik véletlenszerűen megváltoztatni azokat.

Foglaljuk össze az időzítőket:

Az időzítők konfigurálásával óvatosan kell bánnunk, mivel az egyes értékek szoros összefüggésben vannak egymással. Gondoljunk bele: Egy kiterjedt hálózatban időbe telik, hogy minden kapcsoló megkapja a Hello BPDU-t, vagyis amikor végigfut egy BPDU, akkor minden kapcsoló visszaszámlálása máshol fog tartani, hiszen más időpontokban kapták meg az üzenetet. Ennek a problémának a megoldására azt találták ki, hogy egy kapcsoló minél messzebb található a gyökérponti hídtól, annál rövidebb lesz az age time-ja, noha mindegyiken az alapértelmezett 20 másodperc van konfigurálva. Akkor hogy van ez? Úgy, hogy a ténylegesen Hello BPDU érvényességi időt úgy számolja ki a kapcsoló, hogy a konfigurált age time-ból levonja a BPDU message time idejét. (Emlékezzünk rá, a message time idő-t a gyökérponti kapcsoló 0-val küldi, és minden kapcsoló 1-gyel megnövelve küldi tovább.) Minél messzebb van egy kapcsoló a gyökérponti hídtól, annál nagyobb a message time, annál kisebb a BPDU érvényességi ideje (Hello BPDU érvényességi idő = Max Age time – message time), annál hamarabb vár új Hello BPDU-t, ha pedig az nem jön, indítja az STP újraszámítását.  Ez a közeli kapcsolóknál nem okoz gondot, de képzeljük el a legtávolabbi 20. kapcsolót. Ez 19-es message time-mal kapta meg a Hello BPDU-t, 20-szal továbbküldi (a következő kapcsoló emiatt eldobja, hiszen max. a 19), és a BPDU érvényességi idejét alapértelmezetten 20-19=1 másodperccel veszi. Vagyis kap egy Hello BPDU-t, és 1 másodpercen belül várja a következőt, pedig alapértelmezetten 2 másodpercenként jönnek. A 19. kapcsoló ugyanezzel a logikával határon üzemel, vagyis a lejárat után azonnal várja az újat.  Ennyi talán elég legyen ahhoz, hogy mennyire óvatosan kell bánni az időzítők állítgatásával. (Gondoljunk csak arra, hogy ha a Hello BPDU-k küldésének a gyakoriságát csökkentjük – növeljük a Hello időzítő értékét -, már közelebbi kapcsolóknál előáll a fentebb leírt helyzet.) Biztonságosan működő STP-t használó hálózatban ezek miatt maximum 17 kapcsolót használatát ajánlják. (Érdekesség, hogy bevezették a hálózat átmérőjének a fogalmát (network diameter), amely azt takarja, hogy milyen messze van egymástól a két legtávolabbi kapcsoló. Középpontba a gyökérponti kapcsolót képzeljük el. Az STP időzítőinek értéke a 7 átmérőjű hálózatra van beállítva.)

Ha már mindenképpen módosítania akarjuk az időzítőket, akkor a következő szabályokat tartsuk be:

• 2 x (Forward Delay – 1.0 sec) >= Max Age
• Max Age >= 2 x (Hello Time + 1.0 sec)

Ezek szerint a következő időzítő kombináció elfogadható (persze számoljunk a hálózat méretével):

SW1(config)#spanning-tree vlan 1 hello-time 1
SW1(config)#spanning-tree vlan 1 max-age 10
SW1(config)#spanning-tree vlan 1 forward-time 12

Az időzítők megismerése után már választ tudunk adni arra a kérdésre, hogy mennyi idő alatt konvergál az STP? Ez az érték elérheti az 50 másodpercet is, hiszen a feszítőfa kiszámolása előtt akár 20 másodpercet is várhat (max-age), és a figyelő és tanuló állapotokra is elmegy még 15-15 másodperc.  Ez azért jelentős idő, gondoljuk csak el, hogy a hálózati eszközök felkapcsolása után akár 50 másodperc is eltelhet az adatforgalom elindulásáig. Ennyi idő alatt egy PC akár feladja a DHCP kérést is. A protokoll gyorsítása és más gyorsító technikák bevezetése szükségessé vált, de ezekről majd később.

Az STP BPDU-k szerkezete

Rengeteg információt olvastunk eddig az STP-ről, tekintsük át először az eredeti STP konfigurációs BPDU üzenetének a szerkezetét, most már fogjuk érteni az egyes mezők szerepét. Tekinthető ez az eddigiek kis összefoglalásának is: