News & Blog

STP védelmi mechanizmusok

News & Blog

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 protokol time-to-live mezője felelős, vagyis annak detektálása, hogy az adott PDU 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, amely működését viszont több funkcióval is kibőví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 kapcsolót.) Ha egy Root Guard funkciót bekapcsoljuk egy porton, és az egy feljebbvaló BDU-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 kapcsolónk. 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

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ódba kapcsolt 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. 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 BDU 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 porokon, 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.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük