A stp protokoll javítása hurokvédelemmel és bpdu ferdeség érzékeléssel
Az STP protokoll lehetővé teszi a fizikai redundáns topológiákat a fa topológiákban hurkok nélkül. Az STP protokoll legnagyobb problémája az, hogy bizonyos hardverhibák miatt ez a protokoll meghiúsulhat. Ez a meghibásodás továbbító hurkok (vagy STP hurkok) kialakulását eredményezi. Az STP hurkok súlyos hálózati megszakításokat okoznak.
Ez a dokumentum leírja az STP hurokvédelmi funkciót, melynek célja a 2. réteg (L2) hálózatok stabilitása. Itt leírjuk a BPDU veszteség-detektáló funkcióját is. A veszteségjelző funkció BPDU egy olyan diagnosztikai eszköz, amely syslog üzeneteket generál, ha a BPDU csomagokat nem érkezik meg időben.
Ennek a dokumentumnak nincsenek merev kötései a szoftver és a hardver különféle verzióihoz.
Az STP hurokvédelem funkciót először Catalyst 4000 és Catalyst 5000 platformok Catalyst programjának 6.2.1-es CatOS verziójában és a Catalyst 6000 platform 6.2.2 verziójában hajtották végre.
A BPDU veszteségjelző funkcióját először a Catalyst 4000 és Catalyst 5000 platformok Catalyst programjának CatOS 6.2.1 verziójában és a Catalyst 6000 platform 6.2.2 verziójában hajtják végre.
védelmi funkció STP hurkokkal először végre Cisco IOS szoftver 12.1 (12c) EW A Catalyst 4500 kapcsolók és a Cisco IOS szoftver 12.1 (11b) EX Catalyst 6500.
A BPDU veszteségérzékelő funkcióját nem támogatja a Cisco IOS rendszer szoftverrel rendelkező katalizátor kapcsolók.
Belső célokra az STP protokoll a híd egyes portjaihoz (vagy kapcsolójához) hozzárendel a konfigurációhoz, a topológiahoz, a port topológiához és a többi tényezőhöz viszonyított relatív helyzete alapján. A port szerepe meghatározza a port viselkedését az STP protokoll szerint. A hozzárendelt szerepkörtől függően a port elküldi vagy fogadja az STPP BPDU csomagokat és továbbítja vagy blokkolja az adatforgalmat. Az alábbi lista röviden ismerteti az egyes STP-portok szerepét:
Nevezi. Minden egyes kapcsolat (szegmens) esetében egy kijelölt port van kiválasztva. A kijelölt port a gyökérhídhoz legközelebb eső port. Ez a port BPDU csomagokat küld ezen kapcsolat (szegmens) fölé, és továbbítja a forgalmat a gyökérhídra. Egy STP konvergencia topológiában lévő hálózatban minden hozzárendelt port az STP továbbítási állapotban van.
Root. A hídnak csak egy gyökérportja lehet. A gyökérport a gyökérhídhoz vezető port. Egy STP konvergencia topológiában lévő hálózatban a gyökérport az STP továbbítási állapotban van.
Alternative. Az alternatív portok a gyökérhídhoz vezetnek, de nem root portok. Az alternatív portok támogatják az STP zár állapotát.
Reserve. Ez egy különleges eset, amikor ugyanazon híd két vagy több portja (kapcsoló) közvetlenül vagy egy közös szállítón keresztül csatlakozik. Ebben az esetben egy port van hozzárendelve, és a többi port blokkolva van. Ez a port biztonsági másolatot tartalmaz.
Az STP hurokvédelmi funkció további védelmet biztosít a 2. szintű (STP hurok) továbbító hurkok számára. Az STP hurok akkor keletkezik, ha a redundáns topológia blokkolt STP portja tévesen lép be a továbbítási állapotba. Általában ennek az az oka, hogy a fizikailag redundáns topológia egyik portja (nem feltétlenül a blokkolt STP port) megszünteti az STP BPDU csomagok fogadását. Az STP protokoll mûködése függ a BPDU csomagok folyamatos fogadásától és továbbításától a port-szerep alapján. A hozzárendelt port továbbítja a BPDU csomagokat, és a nem hozzárendelt port megkapja a BPDU csomagokat.
Ha a fizikailag redundáns topológia egyik portja megállítja a BPDU-k fogadását, akkor az STP protokollnak ezt a topológiát topológiának kell tekinteni. Ennek eredményeképpen az alternatív vagy tartalék port blokkolt portja a kijelölt port lesz, és megy a továbbítási állapotba. Ebben a helyzetben egy hurok alakul ki.
A loop védelmi funkció további ellenőrzéseket végez. Ha BPDU csomagokat már nem fogadható el nem osztott port és a hurok védelme engedélyezve van, ez a port átkerül a zárt állapot miatt STP hurok képességeit, nem hallgat állapotban, tanulás (learning) vagy a szállítás. A loopback védelmi funkció nélkül a port a kijelölt portként működik. A port az STP továbbítási állapotba kerül, és hurokot képez.
Ha a hurokvédelem egy páratlan portot blokkol, akkor a naplóba a következő üzenet kerül naplózásra:
Ha a BPDU csomagot a blokkolási állapotban lévő port veszi át az STP hurok lehetősége miatt, akkor ez a port egy másik STP állapotba kerül. A kapott blokk BPDU szerint ez azt jelenti, hogy a helyreállítás automatikusan történik, és nem szükséges beavatkozás. A helyreállítás után a következő üzenet kerül naplózásra:
Ennek a viselkedésnek a szemléltetéséhez vegye figyelembe a következő példát:
Az A kapcsoló a gyökérkapcsoló. A C kapcsoló nem kapja meg a BPDU csomagokat a B kapcsolótól a B kapcsoló és a C kapcsoló közötti egyirányú kapcsolat meghibásodása miatt.
Anélkül hurok őr STP blokkolt portot C kapcsoló bemegy az STP hallgat meghatározott időpont után az időzítő MAX_AGE, majd átmegy az átirányítási állapot szünet után kétszeresével egyenlő értékének forward_delay. Ebben a helyzetben egy hurok alakul ki.
Ha a loop védelem be van kapcsolva, a max_age időzítő visszaállítása után a C kapcsoló blokkolt portja a STP hurok lehetősége miatt megszakad. A blokkolt állapotban lévő port az STP-hurok lehetősége miatt nem árulja el a felhasználói forgalmat, így a hurok nem jön létre. (A lezárási állapot a hurok lehetősége miatt valójában egyenértékű a zár állapotával.).)
A hurokvédelem funkció minden egyes port esetében engedélyezett. Azonban, mivel a funkció a hurok őr blokkolja a port STP, gátolja következetlen portok minden VLAN egyénileg (az STP van kialakítva, külön-külön VLAN). Tehát, ha a BPDU csomagokat érkezett a fő kikötő a VLAN csak egy egyéni, akkor blokkolja csak ez VLAN (lefordítva blokkolt állapotát miatt STP körök lehetséges). Emiatt, ha ez a funkció be van kapcsolva a EtherChannel interfész blokkolta teljes csatornát külön VLAN, és nem csak egy kapcsolatot (mert EtherChannel szempontjából STP protokoll egy logikai port).
Mely kikötőket kell védeni a hurkoktól? A legnyilvánvalóbb válasz: a blokkolt portokon. Ez azonban nem teljesen igaz. A hurkok védelmét fel kell venni a nem hozzárendelt portokra (pontosabban a gyökér és alternatív portokon) az aktív topológiák összes lehetséges kombinációjához. Mivel a hurokvédelem nem minden egyes VLAN-nál van beállítva, ugyanazt a (gerinchálózat) portot lehet hozzárendelni egy VLAN-hoz (VLAN) és egy másikhoz rendelve. Figyelembe kell venned a lehetséges átfutási forgatókönyveket is.
Tekintsük a következő példát:
Alapértelmezés szerint a hurokvédelem le van tiltva. A hurokvédelem engedélyezéséhez használja a következő parancsot:
A Catalyst (CatOS) szoftver 7.1-es verziójával (1) kezdődően a hurokvédelem globálisan engedélyezhető minden porton. Valójában a hurokvédelem minden pont-pont kapcsolaton engedélyezett. A pont-pont összeköttetést a kapcsolat kétirányú átvitelének állapota határozza meg. Ha teljes duplex mód van beállítva, a kapcsolat pont-pont kapcsolattá minősül. Beállíthatja vagy felülbírálhatja az egyes portok globális beállításait egyenként.
A hurokvédelem globális engedélyezéséhez futtassa a következő parancsot:
A hurokvédelem kikapcsolásához futtassa a következő parancsot:
A projekt sajátosságaitól függően kiválaszthatja az UDLD funkciót vagy a loop védelmet. Az STP protokollt illetően a legfontosabb különbség a két funkció között az UDLD védelem hiánya a szoftveres problémák okozta STP hibák ellen. Ennek eredményeképpen a dedikált kapcsoló nem küld BPDU csomagokat. Az ilyen típusú hibák azonban (több tucatszor) ritkábban fordulnak elő, mint az egyirányú kapcsolatok által okozott hibák. Az UDLD funkció viszont rugalmasabb lehet az EtherChannelben lévő egyirányú kapcsolatok esetében. Ebben az esetben az UDLD csak a sikertelen kapcsolatokat tiltja le, és a csatorna a fennmaradó kapcsolatok miatt üzemben marad. Ezzel a meghibásodással a hurokvédelem kikapcsolja a portot a zárolási állapotban, mivel egy hurok képes blokkolni a teljes csatornát.
Ezenkívül a hurokvédelem nem működik közös kapcsolatokon és olyan helyzetekben, amikor a kapcsolat a kapcsolat pillanatától egyirányú. Az utóbbi esetben a port soha nem kap BPDU-t, és nem kapja meg őket. Mivel ez a viselkedés normális lehet, ez az eset nem vonatkozik a loop védelemre. Az ilyen forgatókönyvektől való védelmet az UDLD biztosítja.
Amint már említettük, a legmagasabb szintű védelem akkor biztosított, ha az UDLD és a loop védelmi funkciók engedélyezve vannak.
Az STP fa gyökereinek védelme
Az STP gyökereinek védelme és a hurkok elleni védelem funkciói kölcsönösen kizárják egymást. Az STP fa gyökérvédelmet a kijelölt portokon használják, és nem teszi lehetővé a port megváltoztatását. A hurokvédelem a nem hozzárendelt portokon működik, és lehetővé teszi, hogy a port a max_age lejárata után hozzárendelje. Az STP-fa gyökereinek védelme nem engedélyezhető olyan porthoz, amelyen a hurokvédelem engedélyezett. Ha a portvédelem engedélyezve van a porthoz, letiltja az ebben a porton beállított STP-fázis gyökér védelmét.
Gyors és gerinchálózati gyors funkciók feltöltése
A felfelé irányuló gyors és gerinc gyors funkciók átlátszóak, hogy megvédjék a hurkokat. Ha a függvény gerinc gyorsabban átadja a max_age értéket az átkonvergálás során, akkor nem aktiválja a loop-védelmet. A felfelé irányuló gyors és gerinc gyors funkciókról a következő dokumentumok találhatók:
PortFast és BPDU védelem és dinamikus virtuális LAN
A hurokvédelem nem engedélyezhető a PortFast engedélyezett portokhoz. Mivel a BPDU védelem a portfast engedélyezett portokon működik, bizonyos korlátozások vonatkoznak a BPDU védelemre. A hurkok elleni védelem nem engedélyezhető a dinamikus virtuális hálózat portjain, mert a portfast már engedélyezett ilyen portokon.
Megosztott vegyületek
A hurkok elleni védelem nem tartozik a megosztott kapcsolatokba. Ha a megosztott kapcsolatoknál a hurokvédelem engedélyezve van, a megosztott szegmensekkel összekapcsolt csomópontok forgalma blokkolható.
Több kötőfák (MST)
A hurokvédelem az MST környezetben megfelelően működik.
BPDU veszteség kimutatás
A loop védelmi funkciónak helyesen kell működnie a BPDU veszteségérzékelő funkciójával.
Az STP protokoll működése nagymértékben függ a BPDU csomagok időben történő beérkezésétől. Minden hello_time üzenettel (alapértelmezés szerint 2 másodpercenként) a gyökérhíd BPDU csomagokat küld. A nem gyökérhidak nem hozzák létre újra a BPDU csomagokat minden hello_time üzenethez, de megkapják a gyökérhídról továbbított BPDU csomagokat. Ezért minden nem-gyökérhídnak minden VLAN-ban BPDU-csomagot kell kapnia minden hello_time üzenethez. Bizonyos esetekben a BPDU elvész, vagy a híd CPU-ja túlságosan elfoglalt ahhoz, hogy időben továbbítsa a BPDU-t. Ezek vagy más problémák a BPDU csomagok késleltetését okozhatják (ha vannak ilyenek). Ez a probléma megzavarhatja az STP topológia stabilitását.
A BPDU veszteséges észlelés lehetővé teszi a kapcsoló számára a késő BPDU csomagok figyelését, és a rendszergazda értesítése a syslog üzenetek segítségével. Minden olyan port esetében, amelynél a BPDU csomag késleltetése (vagy torzítása) valaha is észlelhető, a késleltetési funkció a legutóbbi késést jelzi, jelezve annak időtartamát. Azt is jelzi, hogy a BPDU maximális késleltetési ideje az adott port számára.
A CPU túlterhelés elleni védelme érdekében egy syslog üzenetet generál, nem minden esetben, amikor a BPDU csomag késik. Az üzenetek létrehozásának gyakorisága 60 másodpercenként egy üzenetre korlátozódik. Ha azonban a BPDU késleltetése meghaladja a max_age értéke 2-el (amely alapértelmezés szerint 10 s), az üzenet azonnal kinyomtatódik.
Megjegyzés: A BPDU veszteség felismerése diagnosztikai funkció. Ha egy BPDU csomag észlelhető, akkor egy syslog üzenetet küld. A veszteségjelző funkció a BPDU nem végez más korrekciós intézkedéseket.
Példa a BPDU veszteségérzékelő funkció által létrehozott rendszernapló üzenetre:
A veszteség-észlelő BPDU minden egyes kapcsolón egyedileg van beállítva. Alapértelmezés szerint ez a funkció le van tiltva. A BPDU veszteség észlelésének engedélyezéséhez futtassa a következő parancsot: