4.9. Az IEEE 802.1Q szabvány

Ennek a sémának a megvalósításához az szükséges, hogy a hidak tudják, hogy a beérkező keretek melyik VLAN-hoz tartoznak. Enélkül az információ nélkül például a 4.47. ábrán látható B2 híd nem tudhatná, hogy a B1 híd felől érkező keretet a szürke vagy a fehér VLAN-on továbbítsa. Ha egy újfajta LAN-t terveznénk, elég könnyű lenne hozzáadni egy VLAN-mezőt a fejrészhez. De mit lehet tenni a leggyakoribb LAN-nal, az Ethernettel, amelynek nem volt semmilyen tartalék mezője egy VLAN-azonosító számára?

Az IEEE 802-es bizottsága 1995-ben szembesült ezzel a problémával. Hosszas viták után megtették az elképzelhetetlent: megváltoztatták az Ethernet-fejrészt. Az új formátumot a 802.1Q IEEE-szabványban adták ki 1998-ban. Ez már tartalmaz egy VLAN-címkét, melyet most röviden bemutatunk. Nem meglepő, hogy nem volt teljesen triviális dolog valami olyasmit megváltoztatni, ami mindenhol olyan jól meghonosodott, mint az Ethernet-fejrész. Íme, néhány a felmerülő kérdések közül:

  1. Ki kell majd dobni a több százmillió meglevő Ethernet-kártyát?

  2. Ha nem, akkor ki fogja előállítani az új mezőket?

  3. Mi lesz azokkal a keretekkel, amelyek már e nélkül is elérték a maximális keretméretet?

Persze a 802-es bizottság (nagyon is) tudatában volt ezeknek a problémáknak, és tudta, hogy mindegyikre megoldást kell találnia – amit meg is tett.

A megoldás kulcsa az a felismerés, hogy a VLAN-mezőket ténylegesen csak a hidak és a kapcsolók használják, nem pedig a felhasználók gépei. Így a 4.47. ábra esetében nem feltétlenül szükséges, hogy a végállomások felé vezető vonalakon is megjelenjenek az ilyen mezők; elég, ha a hidak között menő vonalakon szerepelnek. Tehát a VLAN-ok használatához a hidaknak kell VLAN-képesnek lenniük. Ez a tény teszi a tervet megvalósíthatóvá.

Ami a meglévő Ethernet-kártyák kidobására vonatkozó kérdést illeti: a válasz „nem”. Emlékezzünk csak vissza arra, hogy a 802.3 bizottság még arra sem tudta rábírni az embereket, hogy a Típus mezőt Hossz mezőre változtassák. Ezek után elképzelhetjük, milyen reakció kísérte volna azt a bejelentést, hogy minden meglevő Ethernet-kártyát ki kell dobni. Mindenesetre az új Ethernet-kártyák már meg fognak felelni a 802.1Q előírásoknak, és helyesen töltik ki a VLAN-mezőket.

Mivel vannak számítógépek (és kapcsolók), amelyek nem ismerik a VLAN-t, a kerettel találkozó első VLAN-képes híd helyezi el a VLAN-mezőt, az útvonalon utolsóként szereplő pedig eltávolítja azt. A kevert topológiára hoz példát a 4.48. ábra. Ezen az ábrán a VLAN-képes számítógépek közvetlenül hozzák létre a felcímkézett (azaz 802.1Q) kereteket, és a továbbiakban a kapcsolók ezeket a címkéket használják. A sötéttel jelölt szimbólumok VLAN-képesek, míg az üresek nem.

4.48. ábra - Hidakkal összekapcsolt LAN, amely csak részben áll VLAN-képes eszközökből. A sötéttel jelzett szimbólumok VLAN-képesek, az üresek nem

kepek/04-48.png


A 802.1Q-val a kereteket az alapján színezik, hogy melyik porton érkeztek. Ahhoz, hogy ez a módszer működjön, az összes számítógépnek ugyanahhoz a VLAN-hoz kell tartoznia, ami csökkenti a rugalmasságot. Például a 4.47. ábrán ez a követelmény teljesül az összes portra, amelyhez csak egy számítógép csatlakozik, de nem teljesül a B2 hídnak arra a portjára, amelyhez az elosztó csatlakozik.

Emellett a híd használhatja a felsőbb rétegbeli protokollokat a szín kiválasztására. Így az ugyanarról a portról érkező keretek különböző LAN-okra kerülhetnek attól függően, hogy IP-csomagokat vagy PPP-kereteket szállítanak.

Más módszerek is lehetségesek a szín meghatározására, de a 802.1Q nem támogatja ezeket. Egy példa erre: a MAC-cím alapján lehetne meghatározni a VLAN színét. Ez hasznos lehet, amikor a keretek egy közeli 802.11-es LAN-ról jönnek, amelyben a mozgásban lévő laptopok a mozgási helyüktől függően különböző portokon keresztül küldenek kereteket. Egy MAC-címet rögzített VLAN-ra képeznének le függetlenül attól, hogy melyik porton lépett be a LAN-ba. Ami pedig az 1518 bájtnál hosszabb keretek kérdését illeti, a 802.1Q egyszerűen felemelte a határt 1522 bájtra. Szerencsére, csak a VLAN-képes számítógépeknek és kapcsolóknak kell támogatniuk a hosszabb kereteket.

Vegyük most szemügyre a 4.49. ábrán látható 802.1Q formátumot! A keretben az egyetlen változást két darab 2 bájtos mező hozzáadása jelenti. Az első a VLAN protokollazonosító (VLAN protocol ID), melynek értéke mindig 0x8100. Ez a szám nagyobb 1500-nál, ezért az Ethernet-kártyák nem hosszként, hanem típusként értelmezik. Az, hogy mit tesz egy hagyományos kártya egy ilyen kerettel, bizonytalan, mivel az ilyen keretek elküldését a hagyományos kártyák nem támogatják.

4.49. ábra - A (hagyományos) 802.3 és a 802.1Q keretformátumok

kepek/04-49.png


A második 2 bájtos mező három almezőt tartalmaz. Ezek közül a legfontosabb a VLAN-azonosító (VLAN identifier), ami az alsó 12 bitet foglalja el. Erről szól az egész történet: ez adja meg a VLAN színét, amelyikhez a keret tartozik. A 3 bites Prioritás (Priority) mezőnek semmi köze a VLAN-okhoz, de mivel egy évtizedben úgyis csak egyszer módosítják az Ethernet-fejrészt, és ahhoz is három év és száz ember kell, akkor, ha már egyszer nekiálltak, miért ne raknának bele még valami jó dolgot. Ez a mező lehetővé teszi a szigorú és kevésbé szigorú követelményeket támasztó valós idejű, valamint a nem időérzékeny forgalmak megkülönböztetését, hogy jobb szolgáltatásminőséget lehessen elérni az Etherneten. Erre az Etherneten keresztül történő beszédátvitelnél van szükség (bár az igazat megvallva, az IP-nek is van egy hasonló mezője immár negyed százada, és azt sem használta soha senki).

Az utolsó mezőt igazából nem is CFI-nek (Canonical Format Indicator – kanonikus formátumjelző), hanem CEI-nek (Corporate Ego Indicator – vállalati érdekérvényesítés-jelző) kellene nevezni. A bitet eredetileg arra szánták, hogy megkülönböztessék vele a bitek sorrendjét a MAC-címekben (alsóvég vagy felsővég kódolású), de ez a használat valahogy elsikkadt a viták során. Jelenléte ma már csak arra utal, hogy az adatmező egy nem módosítható 802.5-ös keretet tartalmaz, ami reményei szerint egy másik 802.5-ös LAN-t talál a céljánál, miközben a két hálózat között egy Etherneten halad át. Természetesen ennek az egész elrendezésnek semmi köze nincs a VLAN-okhoz. De hát a szabványosítási bizottságokban is csak úgy működik a politika, mint máshol: ha te megszavazod az én bitemet, én is megszavazom a tiédet.

Mint már említettük, ha egy címkézett keret érkezik egy VLAN-képes kapcsolóhoz, akkor a kapcsoló a VLAN-azonosító alapján keresi ki a táblázatból, hogy melyik porton kell a keretet kiküldeni. De honnan jön a táblázat? Ha kézzel kell összeállítani, mint annak idején a kézi konfigurációs hidakat, akkor ott vagyunk, ahol a part szakad. Az átlátszó hidak szépsége éppen abban van, hogy csatlakoztatás után rögtön működnek, és nem igényelnek semmilyen kézi beállítást. Nagy szégyen lenne elveszíteni ezt a tulajdonságot. Szerencsére a VLAN-képes hidak is képesek automatikusan konfigurálni magukat az elhaladó címkék megfigyelése alapján. Ha például egy 4-es VLAN-címkét hordozó keret a 3-as porton érkezik be, akkor a 3-as porton lévő egyik gép nyilvánvalóan a 4-es VLAN tagja. A 802.1Q szabvány, mely többnyire a 802.1D szabvány megfelelő részeire hivatkozik, kifejti, hogyan kell dinamikusan felépíteni a táblázatokat.

Mielőtt elhagynánk a VLAN-ok útválasztásának témáját, érdemes egy utolsó megfigyelést tennünk. Az internet és az Ethernet világában sokan fanatikus hívei az összeköttetés nélküli hálózatoknak, és hevesen elleneznek mindent, ami egy kicsit is emlékeztet az összeköttetésekre az adatkapcsolati vagy a hálózati rétegekben. A VLAN mégis valami olyasmit vezetett be, ami meglepően hasonlít az összeköttetésekhez. Egy helyesen működő VLAN-ban ugyanis minden keret egy új, speciális azonosítót hordoz, amit a kapcsoló táblázatában arra használnak, hogy kikeressék, hová kell küldeni a keretet. Pontosan ez az, ami az összeköttetés-alapú hálózatokban is történik. Az összeköttetés nélküli hálózatokban a célcím alapján végzik az útválasztást, nem pedig valamiféle összeköttetés-azonosító alapján. Az effajta, mélyben meglapuló összeköttetés-elvűségről az 5. fejezetben még többet is olvashatunk.