Dugó a körforgalomban, avagy a L2-es hurok.

Nem telik el olyan év, mely során legalább folyosói pletyka szintjén ne hallanék rémtörténeteket, “xyz”-nél, L2-es hurok következtében bekövetkezett nagy leállásokról. A leállások után természetesen mindenki levonja a tanulságokat és hasonló esetek jövőbeni elkerülése érdekében megteszi a szükséges védintézkedéseket .. aztán valahogy mégis eljön a következő nem várt alkalom …

Egy kis háttér:

Hogyan működik egy Ethernet switch?

Az Ethernet switchek (bridge-ek) egyfajta tanulási folyamat segítségével jutnak hozzá azon információkhoz, melyek birtokában képessé válnak a forgalom optimális továbbítására. Ezen továbbítás alapját a CAM (Content Adressable Memory) tábla képezi, melybe bejegyzésre kerülnek a kommunikáló állomások MAC (Media Access Control) címei, hozzárendelve a switch adott interfészeihez.

Tanulási folyamat: Az eszköz bekapcsolásakor semmilyen információval nem rendelkezik a környezetéről. Ahogy megérkezik az első keret, a forrás MAC címet hozzárendeli ahhoz az interfészhez, melyen a keret beérkezett és megnézi, hogy a cél MAC cím benne van-e a CAM táblában, de mivel természetesen nincs (hisz ez az első keret), így a keretet továbbítja minden  interfészen (kivéve azon, amelyiken beérkezett). A célállomás válaszának beérkezésekor, a korábban hiányzó MAC cím is bekerül a CAM táblába, innentől kezdve az adott forrás és cél állomás közötti kommunikációt a CAM tábla szerinti bejegyzések alapján továbbítja. Ezt a folyamatot unknown unicast flooding-nak nevezzük  és mindaddig folytatódik, míg a kommunikációban részvevő összes állomás címe be nem kerül a táblába. Hogy teljes legyen a kép, a fenti unicast (1-1) típusú kommunikáción kívül, megemlítünk multicast (1-sok) és broadcast (1-mindenki) kommunikációt is, melyben a cél címek muticast (01:00:5e:00:00:00 – 01:00:5e:7f:ff:ff), illetve broadcast (ff.ff.ff.ff.ff.ff) címek. A multicast és broadcast MAC címek nem kerülnek bejegyzésre a táblába, ezen forgalmak esetén, a fogadó interfész kivételével, a keretek minden egyes interfészen továbbításra kerülnek.
A fenti tulajdonságuk miatt, a switchek amolyan “plug-and-play” módon, mindenféle előfeltétel nélkül egymáshoz kapcsolhatók, ugyanakkor ezen rugalmasság kihasználásával, tervezés nélkül összekapcsolt swicthek-ből alkotott, nagy L2-es hálózatok üzemeltetése tele van kihívásokkal.

Mi az a broadcast vihar?

Broadcast viharnak nevezzük az a folyamatot, amikor a broadcast keretek száma oly mértékben megnövekedik, hogy szó szerint elárasztja a kommunikációs vonalakat, meggátolva ezáltal a normális kommunikációt.

Mi az a L2-es hurok?

A L2-es hálózatot alkotó switchek összekapcsolása történhet hierarchikus, láncolt, vagy akár szövevényes módon is. Ahhoz, hogy egy eszköz kiesése ne okozzon nagy hálózati leállást, gondoskodni kell alternatív kapcsolatokról meglétéről és itt kezdődnek a problémák … . Sajnos a L2-es keretnek – mely az adatot szállítja a két kommunikáló fél között – nincs életciklusa (a L3-as kommunikáció esetében a csomag rendelkezik TTL (Time To Live) mezővel), ezért ha nem hurokmentes a hálózat, akár a végtelenségig ”foroghat” egy hurokban. 

l2_hurok

A fenti egyszerű példával illusztrálva (L2-es hurok kialakulása esetén), egyetlen ARP kérés (broadcast) két keret végtelen körforgását és az eredeti keret duplikált továbbítását eredményezi, komoly többletmunkát adva ezáltal úgy a hálózati eszközöknek, mint a hálózaton kommunikáló végberendezéseknek. Mivel a kialakult helyzetben minden további broadcast keret (az unknown unicast is) növeli a végtelen körforgást végző keretek számát, csak idő kérdése a broadcast vihar kialakulása, mely hatására az egész hálózat (broadcast domain) működésképtelenné válik.  

Elméletileg a fenti hatás csak azon VLAN-ok kommunikációját bénítaná meg, melyekben (vagy melyek között) a hurok kialakult, ugyanakkor a broadcast vihar hatására a switchek oly mértékű többletmunkát kapnak, hogy nem marad szabad CPU ciklusuk a hurokban egyébként részt nem vevő VLAN-ok kommunikációjának biztosítására.

Hogyan kerüljük el a L2-es hurok kialakulását?

A fenti probléma orvoslására került kifejlesztésre a Spanning Tree protokoll (ötletgazda Radia Perlman), mely hibamentes esetben bizonyos kapcsolatok blokkolásával biztosítja a L2-es hálózatok hurokmentességét, mely kapcsolatok dinamikus módon feloldásra kerülnek, amennyiben valamely kapcsolat/eszköz kiesése megszakítja az elsődleges kapcsolaton történő kommunikációt (lásd az alábbi ábrán: hibamentes – kapcsolat hiba – eszközhiba). 

l2_hurok_stp3

Mint azt ahogy maga az ötletgazda is elismerte, a Spannig Tree  protokoll nem a tökéletes, hanem az Ethernet protokoll elterjedésének (olcsó és egyszerű mivolta miatti) hatására kifejlesztett “workaround” megoldás, mely nem képes minden esetben megelőzni a L2-es hurkok kialakulását (pl. duplex mismatch, egyirányú kapcsolat stb.).

Mi a tökéletes megoldás?

  1. Routing (L3 access) alkalmazása minden hálózati eszköz között
      • Előny:
        megoldást jelent a fenti problémára
        az eszközök közötti redundáns kapcsolatok aktív-aktív módban használhatók
      • Hátrány:
        az adatközponti hálózatokban tipikusan nem használható a szerver fürtözési (cluster) technológia korlátai miatt
        mivel minden kapcsolatnak IP címet (tartományt) kell biztosítani jelentős tervezési és adminisztrációs (IP cím/tartomány) többletmunkát igényel
  2. SPB – IEEE 802.1aq – a közelmúltban szabványosított SPB protokollt támogató eszközökkel megvalósított L2 Multi Pathing (L2MP) megoldás
  3. TRILL – az IETF munkacsoport gondozásában, jelenleg már a szabványosítás utolsó fázisában lévő protokollt támogató eszközök alkalmazása (természetesen, majd csak a megjelenésük után Mosolygó arc), vagy a Cisco implementációjában, a TRILL-lel azonos funkcionalitású (és a szabványosítási folyamat lezárta után egy szoftver frissítéssel azt támogató) FabricPath alkalmazása.

Néhány tanács, míg át nem térünk a fenti tökéletes megoldások valamelyikének alkalmazására:

  • Broadcast/hiba domain minimumra redukálása

Mint ahogy az épületekben is vannak tűzzáró ajtók, a hálózatot is szegmentálni kell,  ahhoz, hogy egy kialakult anomália hatása ne terjedjen ki a hálózat teljes egészére. Egy L2-es hálózaton a hiba domain lezárása route-olt porttal (routing) történik.

Csak akkor alkalmazzunk L2-es kapcsolatot a hálózati eszközök között, ha az feltétlenül szükséges (az alkalmazás igényli pl. szerver fürtözés)

A szükséges funkcionalitás biztosítására, igyekezzünk a lehető legkisebb logikai és fizikai kiterjedésű L2-es hálózatok kialakítására, kerüljük az épületek/telephelyek között átívelő L2-es kapcsolatokat.

Adatközpontok között alkalmazzunk olyan L2-es kihosszabbítást (DCI – Data Center InterConnect) támogató megoldásokat, melyek alkalmasak a hiba domain szeparálására (OTV, LISP, VXLAN)

Tagged , ,

Post a Comment

You must be logged in to post a comment.