Mindannyian ismerjük a Portfast konfigurálásának nagy előnyét, egy Portfasttal konfigurált port azonnal elkezdi az adatátvitelt a “forwarding” állapotban, megkerülve a többi spanning-tree állapotot. Ez minden bizonnyal egy nagyszerű funkció, amelyet a végfelhasználói munkaállomáshoz vagy a kiszolgálókhoz csatlakozó downstream portokon kell konfigurálni. Van egy másik nagyszerű ok is a Portfast konfigurálására az ügyfél szélső portjain, amely nem annyira ismert.
Amikor egy switchport felfelé vagy lefelé megy, a switch generál egy TCN (Topology Change Notification) csomagot, és elküldi ezt a TCN csomagot a root bridge-nek, a root bridge pedig egy TCA (Topology Change Acknowledge) csomaggal válaszol vissza, egyszerűen a TCN csomag nyugtázására. A gyökérhíd ezután egy másik BPDU-t küld a TC (Topology Change) bit beállításával a Spanning-Tree tartományon belüli minden kapcsolónak. Amikor a többi kapcsoló megkapja ezt a TC-vel jelölt csomagot, a CAM-tábla (más néven MAC-címtábla) minden bejegyzésének öregedési idejét 15 másodpercre állítja vissza, ami a kapcsolót a saját CAM-táblájának újjáépítésére késztetheti, ha a bejegyzések elkezdenek öregedni. A 2. rétegű hálózat méretétől függően ez sok erőforrást pazarolhat a kapcsolókon. Arról nem is beszélve, hogy sok felesleges forgalmi többletköltséget okoz, mivel a TCN, TCA és TC zászlókkal külön-külön beállított BPDU-kat továbbítjuk. Ne feledje azt sem, hogy ha a CAM-tábla bejegyzései lejárnak, ez felesleges ARP-forgalmat okozhat a kapcsoló által már birtokolt további információkért.
Most nézzünk át néhány dolgot:
Itt van egy portkonfiguráció, portfast nélkül:
Ha leválasztjuk és újracsatlakoztatjuk a fa1/0/5-öt, a következő napló kimenetet kapjuk:
Az előző képernyőképen látható, hogy az első dolog, ami történik, hogy a spanning-tree elküldi a TCN BPDU-t, és az interfészt downnak jelöli. Ezután újra csatlakoztatom a kábelt az fa1/0/5-hez, és láthatjuk, hogy a port átmegy a spanning-tree szakaszain, a figyeléstől a tanulásig és végül a továbbításig. (Extra kredit, a spanning melyik verzióját futtatom?) Amit szintén észre kell venni, az az a tény, hogy egy másik TCN BPDU csomagot küld, amikor a port újra forwarding állapotba kerül.
Most konfiguráljuk a Portfastot ezen a switchporton:
Most ismét kapcsoljuk ki és kapcsoljuk vissza ezt a portot újra:
Sokkal kevesebb történik itt az előző tapasztalatainkhoz képest, a fontos dolog itt az, hogy észrevegyük, nem küldünk TCN csomagot sem akkor, amikor a portot down-nak jelöljük, sem amikor a portot up-nak (vagy forwarding-nak) jelöljük. Az egyetlen STP esemény, ami regisztrálásra kerül, az az, hogy a fa1/0/5 port a blokkoló állapotból közvetlenül a forwarding állapotba kerül, megkerülve a listening állapotot és a learning állapotot, így az ügyfél még gyorsabban elkezdheti használni a hálózatot.
Most, dőljünk hátra a székünkben egy pillanatra és gondolkodjunk el ezen egy percig. A TCN akkor kerül kiküldésre, amikor a switchport leáll, majd újra, amikor a switchport forwarding állapotba kerül. Tehát amikor egy végfelhasználó úgy dönt, hogy újraindítja a számítógépét, amikor lecsatlakoztatja a laptopját, hogy elmenjen egy megbeszélésre, majd ismét visszadokkol az asztalához, vagy amikor úgy dönt, hogy átrendezi az asztalát, és kihúzza a számítógépét, egy TCN-t fog küldeni, ami a switchek számára a MAC-címtáblában lévő bejegyzések öregedési időzítőinek csökkentését eredményezi. Ez rengeteg felesleges erőforrás-felhasználást jelenthet.
Utóirat: Ne felejtse el engedélyezni a BPDU Guardot a portfast engedélyezésekor! A portfast nagyszerű eszköz, de mivel kihagyja a figyelő és tanuló állapotokat, fennáll annak a lehetősége, hogy 2. rétegű kapcsolási hurkokat hoz létre, ha több switchet keresztbe kapcsol, vagy a felhasználók egyszerű switcheket/hubokat kezdenek csatlakoztatni az asztaluknál. A BPDU Guard egy portot Err-Disabled állapotba helyez, ha BPDU-t kap a porton.