A helyi hálózatot ritkán veszi észre bárki, amíg működik. Ha egy maghálózati kapcsoló tápegysége megadja magát, vagy valaki a szerelés közben kihúz egy rossz kábelt, egyszerre áll le a fájlszerver elérése és a telefonközpont. A redundancia arra való, hogy egy ilyen hiba után a forgalom másik úton menjen tovább, lehetőleg úgy, hogy a felhasználók észre se vegyék.
A tartalék út viszont maga is gondot okoz: két kapcsoló között két kábel már hurkot jelent, és az Ethernet nem bírja a hurkot. Ezért a redundáns hálózat több, egymásra épülő mechanizmusból áll, és mindegyik másfajta hibát kezel.
Mi történik, ha kiesik egy kapcsoló
Egy tipikus vállalati hálózat két vagy három rétegből áll. A végpontok a hozzáférési kapcsolókhoz csatlakoznak, ezek felfelé egy elosztó- vagy maghálózati réteghez, ahol a VLAN-ok közötti útválasztás és az alapértelmezett átjáró is található. Hogy egy hiba mekkora kiesést okoz, azon múlik, hol történik és mi van mögötte tartaléknak.
- Ha egy hozzáférési kapcsoló áll le, az összes rá kötött gép, telefon és hozzáférési pont kiesik. Egy egyetlen kábellel bekötött asztali gépnél ez ellen a hálózat oldalán nincs mit tenni, a cél a hiba gyors észlelése és a csere.
- Ha a hozzáférési kapcsoló felfelé vezető kábele szakad el, és csak egy van, a kapcsoló minden végpontja elszigetelődik, pedig maga az eszköz ép.
- Ha a maghálózati kapcsoló esik ki, és rajta van az összes VLAN alapértelmezett átjárója, az egész telephelyen leáll a szegmensek közötti forgalom és az internetelérés.
A tervezés első lépése ezért egy egyszerű lista: mely eszközök és kábelek kiesése állít le egynél több szegmenst. Ezek az egyedüli hibapontok. A felhasználói hozzáférésnél általában elfogadható egy kapcsoló kiesése, a felfelé vezető kapcsolatoknál, a maghálózatnál, a szerverek és a tárolók bekötésénél többnyire nem.
Az áramellátás is ide tartozik. Két tápegység ugyanarról az áramkörről, vagy két kapcsoló ugyanazon a szünetmentes tápon nem ad valódi tartalékot.
Hurokvédelem: STP és RSTP
Az Ethernet-keretben nincs élettartam-számláló, amely egy idő után eldobatná a körbe járó csomagot. Ha két kapcsoló között két párhuzamos út van, a szórásos keretek, például az ARP-kérések, végtelenül köröznek és sokszorozódnak. Pár másodperc alatt kialakul a szórásvihar: a linkek megtelnek, a kapcsolók MAC-táblája folyamatosan átíródik, mert ugyanazt a címet hol az egyik, hol a másik porton látják, és a hálózat használhatatlanná válik.
A feszítőfa-protokoll (Spanning Tree Protocol, STP, IEEE 802.1D) ezt úgy oldja meg, hogy a redundáns utak közül néhányat logikailag letilt, így a fizikai topológiában lévő hurkokból fa lesz. A kapcsolók először gyökérhidat választanak: a legkisebb híd-azonosítójú eszközt, amely a beállított prioritásból és a MAC-címből áll. Ezután minden kapcsoló kiválasztja a gyökérhez vezető legolcsóbb utat, a fölösleges portokat pedig blokkolt állapotba teszi. Ha egy aktív út megszakad, a blokkolt port átveszi a helyét.
Miért lassú a klasszikus STP
Az eredeti STP időzítőkre épül. A szabvány alapértékeivel egy port a hallgatózó és a tanuló állapoton át 2 × 15 másodperc alatt jut el a továbbításig, és ha a hibát közvetve kell észlelni, ehhez még a 20 másodperces max age is hozzájön. Egy kábelszakadás így közvetlen hibánál nagyjából 30, közvetett hibánál közel 50 másodperces kiesést okozhat. A gyors feszítőfa (RSTP, eredetileg IEEE 802.1w, ma az IEEE 802.1D-2004 része) a pont-pont kapcsolatokon a szomszédok közötti egyeztetéssel kapcsol át, ezért jóval gyorsabb. Ahol sok VLAN van, az MSTP (IEEE 802.1Q) VLAN-csoportonként külön fát tud építeni, így a terhelés két felfelé vezető ág között is megosztható.
Beállítások, amelyeken a stabilitás múlik
- A gyökérhidat kézzel kell kijelölni. Alapértelmezésben minden kapcsoló azonos prioritással indul (32768), ilyenkor a legkisebb MAC-cím nyer, ami gyakran egy régi hozzáférési kapcsoló a szekrény sarkában. A gyökér a maghálózati kapcsoló legyen, a másik maghálózati eszköz pedig a tartalék gyökér.
- A végpontokra néző portok edge portként fussanak. Így bekapcsoláskor azonnal továbbítanak, és nem okoznak topológiaváltozást, amikor egy gépet ki- vagy bekapcsolnak.
- Ugyanezeken a portokon legyen BPDU-védelem. Ha valaki egy saját kapcsolót köt az asztali aljzatba, és az feszítőfát futtat vagy hurkot okoz, a port feszítőfa-üzenetet (BPDU) kap, és lekapcsol, így a behozott eszköz nem szólhat bele a fa felépítésébe. Egy feszítőfát nem futtató, egyszerű asztali kapcsolót a védelem csak akkor vesz észre, ha az hurkot hoz létre.
- A gyökérvédelem (root guard) a hozzáférési réteg felé néző portokon megakadályozza, hogy egy onnan érkező, jobb (kisebb értékű) híd-azonosítót hirdető eszköz átvegye a gyökér szerepét.
Az STP-t akkor sem érdemes kikapcsolni, ha a hálózatban elvileg nincs hurok. Szórásvihart gyakran egy véletlenül két aljzat közé dugott patchkábel okoz, és ezt csak a hurokvédelem fogja meg.
Linkaggregáció (LACP)
Az STP a redundáns utak egy részét tétlenül hagyja. A linkaggregáció ehelyett több fizikai kapcsolatot egy logikai kapcsolattá fog össze: a két kapcsoló egyetlen portnak látja a köteget, az STP szempontjából nincs hurok, és minden tagport forgalmat visz. Ha egy kábel elszakad, a forgalom a megmaradt tagokon megy tovább, a feszítőfának nem kell újraszámolnia semmit.
A köteg kétféleképpen jöhet létre. Statikus beállításnál mindkét oldalon kézzel kötik össze a portokat, és egyik eszköz sem ellenőrzi, hogy a túloldal is így van-e beállítva. Az LACP (Link Aggregation Control Protocol, IEEE 802.1AX, eredetileg IEEE 802.3ad) üzeneteket cserél a két oldal között, és csak azt a portot veszi fel a kötegbe, amelyről a túloldal is megerősíti, hogy ugyanabba a kötegbe tartozik. Egy rossz helyre dugott kábel vagy egy hibás oldali beállítás így kimarad a kötegből, ahelyett hogy hurkot vagy fekete lyukat okozna. Ezért az LACP a jobb választás, ahol mindkét oldal támogatja.
Amit a köteg nem tud
A forgalom elosztása folyamatonként történik: a kapcsoló a címekből és portszámokból képzett érték alapján dönti el, melyik tagporton megy egy adott kapcsolat. Egy két 10 Gbit/s-os tagból álló köteg ezért összesen 20 Gbit/s-ot visz, de egyetlen fájlmásolás vagy mentési folyamat továbbra is csak egy tag sebességét kapja meg. A tagportok azonos sebességűek és azonos beállításúak legyenek, ugyanazzal a VLAN-listával.
A legfontosabb korlát: ha a köteg mindkét vége egy-egy kapcsoló, és az egyik kiesik, a köteg is megszűnik.
Stack és több eszközön átívelő linkaggregáció
Eszközkiesés ellen úgy lehet védekezni, hogy a köteg tagjai két különböző kapcsolón végződnek. Ehhez a két kapcsolónak a túloldal felé egy eszköznek kell látszania. Erre két elterjedt megoldás van.
Stack
A stack több fizikai kapcsolót egyetlen logikai eszközzé kapcsol össze, jellemzően külön stackkábellel vagy erre kijelölt portokkal. Egy tag a vezérlő, a stacknek egy konfigurációja és egy kezelőfelülete van, a portok pedig tagonként számozódnak. A linkaggregáció tagjai így tetszőleges stacktagra köthetők: egy szerver két hálózati kártyája két külön fizikai kapcsolóra kerül, mégis egy kötegbe tartozik. Ha egy tag kiesik, a köteg a másikon fut tovább.
Mivel a stack egy vezérlősíkkal működik, egy szoftverhiba vagy egy elrontott konfigurációs parancs az összes tagot egyszerre érinti. A firmware-frissítés sok esetben az egész stack újraindításával jár. Ha pedig a tagok közötti kapcsolat megszakad, és a stack két részre esik szét, mindkét fél vezérlőnek tekintheti magát, azonos IP-címmel és konfigurációval. A gyártók ennek kezelésére külön észlelési mechanizmust kínálnak, ezt be kell állítani.
Több eszközön átívelő linkaggregáció
A másik megoldásnál két önálló kapcsoló marad két vezérlősíkkal, saját konfigurációval, és egy közöttük futó szinkronizáló kapcsolaton keresztül egyeztetik, hogy a túloldal felé egy LACP-partnernek látszanak. A végpont vagy a hozzáférési kapcsoló ebből annyit érzékel, hogy egy szokásos kötegben van. A két eszköz egymástól függetlenül frissíthető, és egyik szoftverhibája nem viszi magával a másikat. Cserébe a beállítás összetettebb, a két kapcsoló konfigurációját összhangban kell tartani, a megoldástól függően részben kézzel, és a megoldás gyártónként eltérő névvel és működéssel érhető el, két különböző gyártó eszköze között nem működik. Külön figyelmet kér a két kapcsoló közötti szinkronizáló kapcsolat: ha megszakad, miközben mindkét eszköz működik, mindkettő a saját feje szerint kezdheti kezelni a kötegeket. A megoldások ezért általában egy független életjel-kapcsolatot (keepalive) is használnak, amelyet a szinkronizáló kapcsolattól külön úton érdemes vezetni.
| Mechanizmus | Mi ellen véd | Mi ellen nem |
|---|---|---|
| STP, RSTP, MSTP | Hurok, kábel- vagy eszközkiesés tartalék úttal | Lassú átkapcsolás (klasszikus STP), a tartalék út tétlen |
| Linkaggregáció két eszköz között | Kábel- vagy portkiesés, plusz sávszélesség | A túloldali kapcsoló kiesése |
| Stack | Egy tag kiesése, ha a kötegek tagokon átívelnek | Közös szoftverhiba, frissítés, stack szétesése |
| Több eszközön átívelő linkaggregáció | Egy kapcsoló kiesése vagy frissítése | Elcsúszott konfiguráció a két eszközön, a szinkronizáló és az életjel-kapcsolat egyidejű kiesése |
| VRRP | Az alapértelmezett átjárót adó eszköz kiesése | Az átjáró mögötti uplink kiesése, ha nincs követés |
Átjáró-redundancia: VRRP
A végpontok egyetlen alapértelmezett átjáró címét ismerik, amelyet a DHCP oszt ki vagy kézzel állítottak be. Ha ezt a címet egy maghálózati kapcsoló adja, és az kiesik, hiába ép a második maghálózati eszköz, a gépek nem tudják, hogy oda kellene küldeniük a forgalmat. Az alapértelmezett átjárót ezért a harmadik rétegben is redundánssá kell tenni.
A VRRP (Virtual Router Redundancy Protocol, a 3-as verzió az IETF RFC 5798-ban, IPv4-re és IPv6-ra) egy virtuális IP-címet és egy hozzá tartozó virtuális MAC-címet hoz létre, amelyen két vagy több útválasztó osztozik. Közülük mindig egy a master, ez válaszol a virtuális címre és továbbítja a forgalmat, a többiek backupként figyelik a master rendszeres hirdetéseit. Ha a hirdetések elmaradnak, a legnagyobb prioritású backup átveszi a virtuális címet. A végpontok ebből semmit nem érzékelnek: az átjáró címe és MAC-címe ugyanaz marad, a kapcsolók pedig az új master első kereteiből megtanulják, melyik porton érhető el.
Amire figyelni kell
- Uplink-követés. Ha a master kapcsoló működik, de az internet vagy a tűzfal felé vezető kapcsolata megszakad, a VRRP magától nem vált át, mert a master továbbra is küldi a hirdetéseit. A felfelé vezető interfész vagy útvonal követésével a master ilyenkor csökkenti a saját prioritását, és átadja a szerepet.
- Preempció. Ha a hiba után a korábbi master visszatér, a preempció beállításán múlik, hogy visszaveszi-e a szerepet. Érdemes némi késleltetést adni neki, hogy csak az útválasztó táblák felépülése után vegye vissza a forgalmat.
- Összhang a feszítőfával. Ugyanabban a VLAN-ban a VRRP master és az STP gyökérhíd ugyanaz a kapcsoló legyen. Ha nem az, a forgalom fölösleges kerülővel, a két maghálózati kapcsoló közötti kapcsolaton át jut el az átjáróig.
Ha a két maghálózati kapcsoló egy stacket alkot, az átjárót egyetlen logikai eszköz adja, és egy tag kiesésekor a stack maga viszi tovább, külön VRRP nélkül. Több eszközön átívelő linkaggregációnál viszont a két kapcsoló két önálló vezérlősík marad, ezért az átjárót ott is redundánssá kell tenni: VRRP-vel, vagy a gyártó erre épülő, mindkét kapcsolón egyszerre aktív átjáró-megoldásával, amely közös virtuális címet és MAC-címet használ.
Tesztelés: kihúzott kábel, kikapcsolt eszköz
Egy félresikerült LACP-beállítás, egy rossz helyre kerülő gyökérhíd vagy egy hiányzó uplink-követés a normál üzemben semmilyen tünetet nem okoz, csak akkor derül ki, amikor egy valódi hiba miatt átkapcsolásra lenne szükség. Ezért a próbát karbantartási ablakban, előre megírt forgatókönyv szerint érdemes elvégezni, amíg a hiba még nem élesben jön elő.
- Előtte rögzíteni kell a kiinduló állapotot: a feszítőfa gyökerét és a blokkolt portokat, a kötegek tagjait, a VRRP master szerepét, a stack vezérlőjét.
- Több végpontról folyamatos pinget kell indítani a saját átjárójukra, egy szerverre és egy internetes címre. A kimaradt válaszok száma mutatja, mennyi ideig tartott az átkapcsolás.
- Egyszerre egy hibát kell előidézni: kihúzni egy kötegtagot, majd egy uplink kábelt, aztán kikapcsolni egy stacktagot, végül a VRRP master kapcsolót. Minden lépés után meg kell várni, hogy a hálózat visszaálljon az eredeti állapotba, és csak utána jöhet a következő.
- A naplóban ellenőrizni kell, hogy a kapcsolók azt csinálták-e, amit a terv szerint kellett, és nem zajlott-e le fölösleges topológiaváltozás a hálózat más részén.
- Az eredményt dokumentálni kell: melyik hiba mennyi kiesést okozott, és mi tért el a várttól.
A tesztnek van egy kevésbé látványos része is. Egy redundáns hálózat a hiba után tartalék nélkül működik tovább, a felhasználók pedig ebből semmit nem vesznek észre. Ha a monitorozás nem riaszt egy kiesett kötegtagra, egy blokkolt állapotból továbbítóvá váló portra vagy egy VRRP-szerepcserére, a második hiba már teljes leállást okoz. A próba során ezért azt is meg kell nézni, megérkezett-e minden riasztás. Hogy a hálózatból milyen adat gyűjthető ehhez, arról a hálózati monitorozásról szóló cikk szól.
Kapcsolódó szolgáltatás: Switching és routing →
