Az adatkapcsolati réteg

Átírás

1 Az adatkapcsolati réteg Az OSI modell szerinti második réteg az adatkapcsolati réteg (Data Link Layer). A réteg általános feladata, hogy egy azonos médiára (pl. kábelre) kapcsolódó készülékek közötti adatátvitelt segítse. Főbb feladatai: Keretképzés: a hálózati réteg adataiból képzi, ill. a fizikai bitfolyamból felismeri. Hibavédelem: küldendő adatok kódolása, hogy az esetleges hiba detektálható legyen. Nyugták generálása, fogadása. Adatfolyam vezérlés (flow control, forgalom szabályozás): az adás sebességét a vevő feldolgozási sebességéhez igazítja. Kapcsolat menedzselése: az összeköttetés létrehozása, a kapcsolat jellemzőinek egyeztetése, kapcsolat lebontása. Demultiplexer funkció: a vett keretek adatmezőjének tartalmát a keret fejrészében meghatározott folyamatnak adja át. Az adatkapcsolat rétegben dolgozó protokollok a fenti feladatokat különböző módon és mértékben valósíthatják meg. Például a LAN technológiákkal foglalkozó IEEE 802 számú szabvány az adatkapcsolati réteget a következő két alrétegre bontotta: logikai-kapcsolat vezérlő (Logical Link Control, LLC) alréteg közegelérést-vezérlő (Media Access Control, MAC) alréteg (opcionális szerepű) A MAC alréteg az üzenetszórást használó média (csatorna) pl. Ethernet hálózat esetén jut szerephez azzal, hogy szükség esetén pont-pont jellegű kapcsolatot hoz létre, míg egy eleve pont-pont kapcsolatot biztosító csatorna (pl. modem) esetén elég csak az LLC megvalósítása. Két gép hálózati protokollja közötti adatcsomag egy keretben (frame) jut át a hálózaton: Hálózati réteg Hálózati protokoll CSOMAG Adatkapcsolati réteg LLC protokoll LLC CSOMAG MAC protokoll MAC LLC CSOMAG MAC Fizikai réteg Média pl. elektromos jelek Amikor például az Ethernet hálózatok jellemzőit és működését vázoljuk, akkor tulajdonképpen az IEEE (CSMA/CD) szerinti MAC protokoll és az IEEE szerinti TYPE I. LLC protokoll egy realizációját ismertetjük. Maga a hálózati kártya (NIC) az IEEE 802.3, a kártya driver pedig az IEEE ajánlás megvalósítása. Az IEEE szerint az LLC alréteg nyújt (MAC technológia független) szolgáltatásokat 1 a hálózati rétegben található klienseinek. (Általánosan is igaz, hogy egy felsőbb réteg az alatta lévő réteggel kliens-szerver kapcsolatban áll és ez általánosan minden szomszédos rétegre érvényes.) A kliensek (pl. a hálózati protokollt 2 megvalósító folyamatok) leggyakrabban adatátvitelre vonatkozó szolgáltatás kéréssel fordulnak az LLC réteghez, mint szerverhez. Az adatátvitel talán legegyszerűbb esete az, amikor két különböző gépen van egy adó és egy vevő. A példa kedvéért az adó és a vevő legyen a két gépen futó hálózati protokollt megvalósító alprogram, amely az LLC alréteg szolgáltatásait, ún. szolgáltatás-hozzáférési pontokként (Service Access Point, SAP) tudja elérni. Egy-egy ilyen logikai ponton keresztül, ún. logikai kapcsolatvezérlési protokoll adatblokkot 3 lehet mozgatni. Amit mi egyszerűen adatátviteli feladatnak neveztünk, azt valószínűleg az LLC több szolgáltatásának, azaz különböző SAP-ok igénybevételével tudják megvalósítani az LLC kliensei. A feladat még összetettebb, ha figyelembe vesszük, hogy minden szolgálat több, ún. primitív segítségével írható le. Az OSI modellben használatos általános primitívek: a kliens egy kérése a szerver felé, a távolvégi kliens részére egy bejelentést okoz. Nyugtázott (megerősített) szolgáltatások esetén a távolvégi kliens a bejelentésre egy választ ad, amely a közelvégi kliens számára egy nyugtát (megerősítést) hoz létre. 1 Szolgáltatás: olyan elemi műveletek halmaza, amelyet egy réteg a felette lévőnek biztosít. A gyakorlatban a protokollok valósítják meg a szabvány szerint szükséges elemi műveleteket, az ún. szolgálati primitíveket. 2 A protokoll az adó és vevő protokoll vermének (protocol stack vagy más néven protokoll készlet) azonos szintjei között teremt logikai kapcsolatot. (Tehát az egyik entitás (pl. számítógép) IP-t megvalósító programja a másik gép, IP-t megvalósító programjával van kapcsolatban). A protokoll leírja, hogy milyen szabályokat kell betartani és milyen eljárásokat kell használni annak, aki az adott protokoll szerint működik. 3 LLC Protocol Date Unit (LLC PDU) IV Szarka T.

2 Pl. egy ETHERNET kártya és driver több, a hálózati rétegben implementált protokoll adatátviteli igényét is képes kiszolgálni. Ezeket a klienseket az általuk használt SAP 4 különbözteti meg, amely gyakorlatilag egy protokoll azonosító konstans. (A bevezetőben említettük, hogy az LLC alréteg szolgáltatásait különböző SAP-ok szimbolizálják. Az utóbb említett SAP az LLC egyik konkrét szolgáltatásának tekinthető.) A hálókártya hardver (NIC) nem tudja, hogy melyik alkalmazás adataival dolgozik, mert ennek adminisztrálása az LLC feladata, amit a kártya driver programja végez. Az LLC alréteg multiplexálja az LLC PDU-kat a MAC felé és demultiplexálja az LLC DPU-kat a kliensek felé. A következő modell az Ethernet interfészek kommunikációját bontja alfeladatokra: LLC PDU ARP-től LLC PDU IP-nek LLC PDU Stb.-nek LLC PDU ARP-nek LLC PDU IP-től LLC PDU Stb.-től SAP 1 SAP 2 SAP n SAP 1 SAP 2 SAP n LLC ( NIC driver) MAC ( a NIC beépített intelligenciája) Fizikai réteg (a NIC) LLC MAC Fizikai réteg kábel Az ábrán összefoglalva látható az, amit ebben a fejezetben tárgyalunk: 1. A fizikai réteghez tartozó közegen (itt egy kábelen) és ennek csatlakozóin bitek áramlanak. Mi ezeket és az ezeket reprezentáló jelsorozatokat nem vizsgáljuk, csak az a fontos nekünk, hogy a fizikai réteg adatátviteli szempontból összekapcsolja a gépeket, így a jelsorozat minden csatlakoztatott géphez eljut. 2. A MAC alréteg szintjén a bitek kereteket alkotnak. (A kereteket már jobban megvizsgáljuk, mert a hálózati adatforgalom alapjai.) A keretek tartalmazzák annak a két gépnek (az adónak és a vevőnek) az azonosítóját, azaz a fizikai (tehát MAC szinten érvényes) címét, amelyek a közeget éppen használják. A MAC nekünk lényegében két plusz szolgáltatás miatt fontos: 1. képes a közeget (a hálózat közös erőforrását) megszerezni adás céljára (az erre használt eljárásokat (CSMA/CD, CSMA/CA, stb. már korábban megismertük). 2. képes a közegen lévő jelsorozatból eldönteni, hogy az éppen neki szól-e. (Másképpen megfogalmazva képes saját MAC címét felismerni.) Ha neki szól, akkor keretté állítja össze, ellenőrzi a keret hibátlanságát, majd hibamentes keret esetén azt átadja az LLC alrétegnek. 3. Az LLC alréteg képes a különböző típusú MAC keretekben felismerni a SAP jellegű mezőt, amelynek tartalma alapján egy meghatározott kliensének adja át a keretben található adatokat. (Ez az LLC alréteg demultiplexer funkciója). (Az LLC alréteg más szolgáltatásait itt nem vizsgáljuk, mert azokat Ethernet lényegében alig implemetálja.) 4 Service Advertising Point. Előre szabványosított konstansok, amelyek az egyes protokollokat jelölik IV Szarka T.

3 Megjegyzés: ha Ethernet helyett más pl. V.24, V.35, stb interfészeket használunk, akkor a pont-pont jellegű technológia miatt nincs szükség a MAC alréteg szolgáltatásaira: a közeget nem kell megszerezni és a közegen megjelenő jelsorozat mindig az egyetlen vevőnek szól. Visszatérve az előző példájára az adó LLC szintű protokolljának az a feladata, hogy (támaszkodva a MAC alréteg és a fizikai réteg szolgáltatásaira) a vevő LLC protokolljával együtt kiszolgálja a kliensek, pl. a hálózati protokollt megvalósító folyamatok közötti adatátviteli igényt. Ennek során az LLC-LLC közötti virtuális kommunikációt ún. keretek (frame-k) reprezentálják, amelyek továbbítása az alsóbb rétegek által biztosított fizikai kommunikáció során valósul meg. Az egyes rétegek (most konkrétan az LLC alréteg) által nyújtott szolgáltatás jellege lehet: Összeköttetés mentes (nyugtázatlan) szolgáltatás: az egymást követő kereteket egymástól függetlenül küldik. A küldő LLC számára nem derül ki, hogy a küldött keret hibamentesen megérkezett-e. Az esetleges hibák kezelése a felsőbb rétegek feladata. Összeköttetés mentes (nyugtázott) szolgáltatás: hibamantes átvitelt valósít meg a megérkezett keretekről küldött nyugta segítségével. Összeköttetéses szolgáltatás: a keretek küldését az adó és vevő közötti egyeztetési folyamat előzi meg. Ennek során megbízható kapcsolat (összeköttetés) jön létre az adó és vevő között. Nyugtázás, sorszámozás és újraküldés segítségével garantálja a szolgáltatás, hogy a küldési sorrenddel megegyező sorrendben érkeznek meg a keretek. Üzenetszórásos technológiák általában összeköttetés mentes szolgáltatást nyújtanak TCP/IP protokoll verem esetén: Token Ring hálózaton nyugtázott összeköttetés mentes kapcsolat van a NIC-ek között. ETHERNET kártyák általában nyugtázatlan összeköttetés mentes kapcsolatban állnak egymással. Tudjuk azonban, hogy valójában az LLC alrétegben implementált protokolltól függ, hogy (pl. az előbbi technológiákra építve) összeköttetéses vagy összeköttetés mentes kapcsolatot nyújte a kliensei számára. (Pl. a Microsoft által korábban támogatott NetBEUI nevű hálózati protokoll az LLC alréteg szintjén valósította meg (igény esetén) az összeköttetéses szolgáltatását Ethernet környezetben!) Adáskor az LLC alréteg a hálózati rétegtől (a kliensétől) kapott LLC PDU-t elhelyezi az általa kialakított MAC fejléc után, majd az egész MAC keretet berakja a NIC adási pufferébe. Ezt követően utasítja a hálókártyát, hogy küldje a memóriában található adatszerkezetet az átviteli közegre. A NIC a vevő működését segítendő, kezdő és végjellel látja el az adatszerkezetet, majd Manchester kódolást használva bitenként a médiára küldi. Adás alatt az átviteli közegen figyelő NIC-ek közül valamelyik valószínűleg felismeri sajátjaként a MAC fejlécben elhangzó címet és ezért feljogosítva érzi magát arra, hogy az egész adatszerkezetet a vételi memóriájának területére helyezze. Amennyiben kiderül, hogy nem sérült a beérkezett adatszerkezet, akkor a MAC protokoll értesíti az LLC protokollt, hogy egy keret beérkezett. Az LLC megvizsgálja a beérkezett keret protokoll azonosítóját, majd az így kiválasztott protokollt megvalósító folyamatnak átadja az LLC PDU-t. A továbbiakban először az ETHERNET hálózatokon használatos keretekkel ismerkedünk meg IV Szarka T.

4 NIC generálja Preamble 8 IEEE típusú Ethernet keret, LLC betéttel Cél MAC címe LLC generálja LLC PDU (Az LLC kliensétől v. kliensének) MAC fej LLC fej LLC adat Adó MAC címe Hossz 2 DSAP 1 SSAP 1 CONTR 1 ADAT Preamble mező: (8 bájt) A NIC-en elhelyezkedő MAC protokollt megvalósító chip az adás kezdetén magától generálja. Az adó azért bocsátja ki, hogy a vevő(k) szinkronba kerüljenek az adóval. Az első 5 bit tartalma: , majd az utolsó 8 bit , így jelzi a chip MAC fej kezdetét. Ezt a mezőt, semmilyen későbbi hossz számításban nem vesszük figyelembe. A cél NIC fizikai (MAC) címe ( bájt): első megközelítésben minden Ethernet kártyának bájtos egyedi címe van. A címkiosztás XEROX által központosított módszere elvileg garantálja, hogy a világon ne legyen két azonos fizikai című kártya. A cím 48 bitjéből 22 bitet a XEROX fenntartott a NIC gyártók, ill. egyéb gyártók fölötti szervezetek azonosítására. Egy-egy gyártó 24 bittel rendelkezik, hogy egymástól megkülönböztesse a saját legyártott kártyáit. A maradék 2 bitet a fizikai címek jellegének leírására használják. A gyártók 24 bites címkomponenseit az IEEE osztja ki (részletet): 00:00:02 BBN 00:00:0C Cisco 00:00:0E Fujitsu 00:00:0F NeXT 00:00:10 Sytek/Hughes LAN Systems 00:00:11 Tektronics 00:00:15 Datapoint 00:00:18 Webster 00:00:1A AMD? 00:00:1B Novell/Eagle Tech. 00:00:1D Cabletron 00:00:20 Data Industrier AB 00:00:21 SC&C 00:00:22 Visual Technology 00:00:23 ABB 00:00:29 IMC 00:00:2A TRW 00:00:3C Auspex 00:00:3D ATT 00:00:44 Castelle 00:00:4 Bunker Ramo 00:00:49 Apricot 00:00:4B APT 00:00:4F Logicraft 00:00:51 Hob Electronic 00:00:52 ODS 00:00:55 AT&T 00:00:5A SK/Xerox 00:00:5D RCE 00:00:5E IANA 00:00:1 Gateway 00:00:2 Honeywell 08:00:0A IBM 00:AA:00 INTEL Például két gyártó által előállított kártyák MAC címe, ahol XX tetszőleges értékű bájt: IBM 08:00:0A:XX:XX:XX INTEL 00:AA:00:XX:XX:XX Egy MAC címet darab hexadecimális számmal írunk le, például: 08:00:0A:33:24:00 A fizikai (MAC) cím a médián való megjelenési sorrendben 7 és bitenként részletezve: G/I bit U/L bit 22 bit a gyártót jelöli 24 bit a gyáron belül A MAC címekben két bitnek kitüntetett szerepe van: G/I bit különbözteti meg az egyedi (Individual) címet (0) és a csoportcímeket (Group) (1). U/L bit különbözteti meg a gyárilag kiosztott (Universally administered) címet (0) a nem hivatalos, helyi rendszergazda által kiadott (Locally administered) címtől (1). LLC gen. PAD x NIC gen. CRC 4 5 Ezt a 8 bitet külön elnevezték: keretkezdet határoló. Mindaddig, amíg szoftveresen át nem állítjuk a kártyánk fizikai címét. 7 Az RS232 interfészre is az volt a jellemző, hogy az adás alatt lévő bájt 0. bitje került először a vonalra IV Szarka T.

5 Az Ethernet keret mezői kapcsán meg kell említenünk, hogy a több bájtos adatok ábrázolása az ún. nagy endián rendszert követi, amely azt jelenti, hogy az adatszerkezet legnagyobb helyiértékű bájtja kerül az adatszerkezet által elfoglalt memóriaterület legkisebb címére. Az általunk használt INTEL processzorokra viszont a kis endian típusú adattárolás jellemző, ezért az erre a processzora készített adatszerkezetek esetében szükséges lehet egy bájtsorrend konverzió. Tegyük fel, hogy a programunkban az ethernet keret kétbájtos hossz mezőjét egy WORD típusú változó segítségével kezeljük. Ha a mező értékét a változóba áttöltjük és a változó értéke, pl. 1234H lesz, akkor a hossz mező valójában 3412H-t tartalmazott! Az viszont más kérdés, hogy ilyen értékű hossz mező nem lehet. (A MOTOROLA gyártmányú processzorok szintén nagy endian módon tárolják a szavakat, ezért ha korábbi APPLE-re fejlesztünk, akkor nincs (ilyen) problémánk, mert a hálózati bájtsorrend (network order) megegyezik a hoszt oldali bájtsorrenddel (host order). Elegánsan is megoldható ez a probléma: pl. egy CD-ROM esetén, mindkét alakban rögzítik a vezérlő információkat és lám ezt a médiát mindegyik rendszerben probléma nélkül lehet használni!) Visszatérve a fizikai címekhez, ügyeljünk tehát arra (legalábbis IBM PC-s környezetben), hogy a cím legnagyobb helyiértékű 8 bájtja van (vagy legyen) a cím által elfoglalt memóriaterület kezdőcímén és ezt követik az egyre kisebb helyiértékű bájtok. Az egyedi, más szóval unicast cím azt jelenti, hogy csak egy NIC-nek lett címezve a keret, illetve az adó címeként mindig ilyen címet használunk. A csoport (multicast, többesküldés) cím jelentősége az, hogy több (az adott csoportba tartozó) NIC számára nem kell külön kereteket küldeni, mert egy darab multicast címzésű kerettel az összes csoporttagnak küldhető üzenet. Csak cél címeként használható csoportcím. Üzenetszóró (broadcast) címzést akkor használnak, ha a hálózat minden gépének (pontosabban NIC-nek)szól az üzenet. Csak cél címeként használható broadcast cím. (Később bemutatjuk, hogy a NIC promiscuous üzemmódban minden keretet vesz a célcímtől függetlenül!) Összefoglaljuk a fogalmak kiemelt fontossága miatt: Unicast címet akkor használunk, ha a keretnek a hálózaton egy címzettje van. Multicast címet kell használni, ha a keretnek a hálózaton több címzettje van. Broadcast címmel érhető el, hogy a keretet a hálózaton mindenki vegye. Az átviteli közeg terhelését csökkenti a multicast és broadcast címzési mód, mert nem kell minden érintettnek külön-kölön elküldeni a keretet. Broadcast (üzenetszóró, adatszóró) címben minden bit egyes értékű FF:FF:FF:FF:FF:FF Csoportcím a G bit beállításával képezhető az egyéni NIC címből. Az egyik előbbi MAC címből: IBM 09:00:0A:..:..:.. (Fentebb olvashattuk, hogy miért nem 88:00:0A:..:..: lett.) Az adatkapcsolati réteg protokoljai, amelyek multicast címet használnak (részlet): CISCO Discovery Protocol: C CC CC CC Bridge Spanning Tree: C A csoportos címzés igényével gyakran valamelyik felsőbb réteg alkalmazása jelentkezik: A Media Services (W2K szerver) egy csoport számára sugároz valamilyen anyagot, pl.: filmet, Power Point prezentációt, stb. Az Exchange 2000 Conferencing Server segítségével többrésztvevős konferenciát lehet létrehozni. A Windows indulásakor a routerek számára fenntartott csoportcímre címre küldött Router Solicitation üzenettel képes megkeresni a Default Gateway-t. A fenti alkalmazások a hálózati réteg által biztosított csoportcím használati lehetőségre épülnek, azaz a hálózati rétegben az IP címtér csoportcím alteréből ( ) származó hálózati címeket használnak. A hálózati rétegben megjelenő csoportcím használatot a MAC alrétegnek is támogatnia kell fizikai szintű csoportcímekkel. 8 Lehet, hogy a cím legbaloldalibb bájtja helyesebb lenne IV Szarka T.

6 Ezért a fenti alkalmazások dinamikusan konfigurálják a hálózati kártyát úgy, hogy a NIC által vizsgált csoportos MAC címek közé fölveszik az adott alkalmazás által használt (csoportos IP) címből a csoportcímzésre fenntartott MAC címtartományban ( E E-FF-FF-FF) kialakított MAC címet. Ehhez az alkalmazás az általa használt csoportos IP cím utolsó 3 oktettjét használják fel a konkrét MAC cím kialakítására. Például a csoportcímet használó alkalmazások a következő MAC címet rögzítik a NIC-ben: E-C Mivel a csoportcímet csak célként használják nem okoz gondot a MAC címek egyezősége. Maradt azonban egy apró probléma, amely abból származik, hogy az IP cím 4 hasznos bitje nem vesz részt a MAC cím kialakításában. Ezért előfordulhat, hogy különböző (csoportos) IP címekhez azonos MAC cím tartozik. Adó NIC fizikai (MAC) címe mező: ( bájt). Bár nem kötelező, de leggyakrabban megegyezik az adó NIC MAC címével. Hossz mező: Az LLC PDU méretét tartalmazza. Egy ETHERNET keret (preamble nélkül)max bájt, ill. min. 4 bájt hosszú lehet. Ha figyelembe vesszük a MAC keret és az LLC fej számára fenntartott bájtokat, akkor az LLC adatbájtok száma közötti lehet 9 : Mező: Méret (bájt): MAC cél MAC küldő Hossz 2 LCC fej 3 CRC 4 Összesen 21 A táblázat a keretben elhelyezett (LLC) betét esetére készült! A hossz mező szó hosszúságú, ezért vigyázzunk a bájt sorrendre! Az Ethernet kereten belül most elérkeztünk az LLC PDU-t alkotó mezőkhöz, azokat mintegy kinagyítva megvizsgáljuk a szabvány (IEEE (LLC)) szerint TYPE 1 10 PDU nevű adatszerkezetet, amely segítségével az LLC alréteg és a kliense közötti kapcsolat zajlik. Ezt a TYPE 1 adatszerkezet típust akkor használják, ha összeköttetés mentes kapcsolatot kell kialakítani az LLC rétegek, ill. az általuk kiszolgált kliensek között. Ezt jelzi az Unnumbered Information frames minősítése, amely arra utal, hogy az LLC fejlécben nincs a keretek sorszámozására utaló mező, tehát összeköttetés mentes szolgáltatásról van szó. LLC PDU LLC fejléc LLC adat DSAP SSAP CONTROL Adatok (pl. IP fejléc +adatok(tcp fejléc + adatok) 1 bájt 1 bájt 1 bájt n bájt SSAP (Source Service Access Point). Az adott LLC PDU-t küldő alkalmazást (az LLC egy kliensét) azonosítja, tehát a SAP mezők az LLC kliensek megkülönböztetésére, "címzésére" szolgálnak. Az SSAP mindig egyedi cím. (A küldő lehet egy protokoll, egy alkalmazás vagy általánosítva egy kliens, ahogy tetszik, mert az LLC nem tesz különbséget a kliensei között az alapján, hogy azok melyik rétegben vannak implementálva.) 9 A később bemutatandó más típusú Ethernet keretek esetében az LLC adatmező mérete ettől eltérő is lehet. 10 Az LLC TYPE 1 protokoll csak a nevében protokoll, valójában egy transzparens réteg a hálózati és MAC réteg között, amelyben nincs implementálva protokoll. A TYPE 1 csak arra kellett, hogy egy piaci súllyal rendelkező termékhez (ETHERNET-hez) alakítsák a szabványt IV. 15. Szarka T.

7 DSAP mező (Destination SAP). A cél alkalmazást (klienst) jelöli, tehát meghatározza, hogy az adott PDU-t melyik kliensnek adja át az LLC alréteg. Unicast, multicast vagy broadcast cím lehet. Egyedi címnél (az adott számítógépen belül) csak egy kliens (protokoll) kapja, multicast címnél több és broadcast cím esetén az összes kliens megkapja az LLC PDU-t. (Legalábbis a MAC alréteg által megcímzett hoszton 11 biztosan, mert a megcímzett hosztot (hosztokat) itt nem látjuk, csak a MAC célcímből derül(nek) ki.) Az alkalmazások egységes megkülönböztetése érdekében a gyakori kliensekhez központilag rendeltek SAP értéket. Néhány konkrétum (a félkövér protokollokkal később találkozunk a jegyzetben): 00 Null LSAP (Management az LLC rétegek egymás közötti kommunikációjához.) 02 Individual LLC Sublayer Management Function 03 Group LLC Sublayer Management Function (csoportcím) 04 IBM SNA Path Control (individual) 05 IBM SNA Path Control (csoportcím) 0 ARPANET Internet Protocol (IP) 08 SNA 0C SNA 0E PROWAY (IEC955) Network Management & Initialization 42 IEEE Bridge Spannning Tree Protocol 4E EIA RS-511 Manufacturing Message Service 7E ISO 8208 (X.25 over IEEE Type 2 LLC) 80 Xerox Network Systems (XNS) 8E PROWAY (IEC 955) Active Station List Maintenance 98 ARPANET Address Resolution Protocol (ARP) BC Banyan VINES AA SubNetwork Access Protocol (SNAP) E0 Novell NetWare F0 IBM NetBIOS F4 IBM LAN Management (individual) F5 IBM LAN Management (csoportcím) F8 IBM Remote Program Load (RPL) FE ISO Network Layer Protocol FF Global LSAP (broadcast) Összefoglalva: a SAP-ok lényegében 7 bites kliens azonosítók (protokoll címek), nyolcadik bitjük speciális szerepű, amint az később az LLC fej bitenkénti leírásából kiderül. (A kliensek megkülönböztetése eléggé korlátozott 8 biten, ezért fejlesztették ki az ebből a szempontból rugalmasabb ETHERNET-SNAP keretet.) CONTROLL mező meghatározza, hogy az LLC protokollok kapcsolatában milyen parancsot ad, vagy milyen parancsra válaszol a küldő. A teljes LLC fej részletesen: DSAP SSAP CONTROL D D D D D D D I/G S S S S S S S C/R MMM P/F MM 1 1 Individual (0): egyéni (egy kliensnek szóló) cím. Group (1): csoportos cím (több kliens megkapja az LLC PDU-t). Destination: A vevő kliens címe Command (0): parancs (a klienstől jön) Response (1): válasz a kliensnek Source: a küldő protokollt azonosítja, mindig egyéni cím. M: Az LLC szolgáltatásait kiválasztó bitek Poll/Final (0/1): A Poll értéke arra utal, hogy még nem ért véget egy adott kerettel a logikailag összetartozó keretek sorozata. Ethernetnél ennek nincs jelentősége. 11 HOST: Régebben a központi számítógép. Napjainkban minden olyan hálózati eszközt így nevezhetünk, amelynek saját hálózati címe van és képes a kapcsolattartásra hálózaton keresztül. (PC, printer, gateway.) IV Szarka T.

8 Tehát a CONTROL bájt határozza meg, hogy a SSSSSSS című kliens milyen szolgáltatást kér az LLC-től, illetve az LLC ezzel jelzi, hogy milyen parancsra ad választ a DDDDDDD című kliensnek. A lehetséges szolgáltatások: CONTROLL=03H Unnumbered Information (UI) paranccsal úgy tudunk adatokat küldeni a vevő LLC-nek (ill. a kliensének), hogy nem rendelünk az adott kerethez sorszámot és nem várjuk a küldött keret megérkezésének visszaigazolását sem. Tehát összeköttetés mentes és nyugtázatlan szolgáltatásra használható, ahol az LLC az adatokat egyszerűen tovább adja a DSAP-ban megadott kliensnek. Az SSAP mezőben C=0 a parancs kiadásakor: DSAP SSAP CONTROL Adatbájtok D D D D D D D I/G S S S S S S S x Az egy másik történet, ha pl. a szállítási rétegben majd biztosítják nyugtázott összeköttetéses szolgálatot az ezt igénylő (pl. banki) alkalmazások számára. Pl. a TCP/IP esetén látunk erre példát. Térjünk vissza az LLC PDU adatmezőjéhez. Érdeklődőknek ismertetjük az LLC TYPE 1 (IP, ARP által nem használt) egyéb parancsait: XID: Exchange Identification paranccsal LLC kérdez le LLC-t, hogy az milyen típusú szolgáltatással rendelkezik és mennyi adatot tud fogadni (milyen az ablak mérete). A parancs kódja: 0AFH vagy 0BFH a P/F bit értékétől függően és a C/R bit 0: DSAP SSAP CONTROL DDDDDDDI/G SSSSSSS A válaszban DDDDDDD tartalma helyet cserél SSSSSSS-el. A C/R=1 és a CONTROL mező után az LLC által generált (!) adat érkezik: 81H, 01H, 00H az Ethernet esetén. A válasz mezői: + DSAP SSAP CONTROL DDDDDDDI/G SSSSSSS FORMAT CLASS WINDOW XXXXXXXX 000YYYYY ZZZZZZZ0 XXXXXXXX= Basic XID formátumú a válasz. Ekkor a következő a mezők jelentése: YYYYY=00001 TYPE I. szolgáltatással rendelkezik az LLC YYYYY=00011 TYPE II. szolgáltatással rendelkezik az LLC ZZZZZZZ= Az ablak mérete (Kbyte). (Az LLC ennyi adatot képes fogadni anélkül, hogy a kliense ürítené a vételi bufferét.) TEST: Test Frame paranccsal LLC tud LLC-nek próbaképpen adatokat küldeni. A parancs kódja: 0E3H vagy 0F3H a P/F bit értékétől függően és C/R bit 0: DSAP SSAP CONTROL Adatbájtok DDDDDDDI/G SSSSSSSC/R A TEST válaszban DDDDDDD tartalma helyet cserél SSSSSSS-el és C/R=1. A válaszban a CONTROL mező után az elküldött adatok is visszajönnek IV Szarka T.

9 IEEE (LLC) szerint TYPE 2 PDU Az eddig tárgyalt TYPE 1 mellett létezik egy másik LLC PDU formátum is, amely összeköttetéses szolgáltatást támogat. Lehetőséget ad sorszám-ellenőrzésre és nyugtázásra, valamint csúszóablakos pufferelésre 12. Ethernet hálózatban a TYPE 2 PDU nem TCP/IP esetén, hanem pl. NetBEUI protokollnál fordul elő. A kapcsolat orientált (tehát összeköttetést biztosító) szolgáltatásoknál az LLC PDU átküldése előtt kapcsolatot kell létrehozni az adó és vevő között, majd a kapcsolatot fenn kell tartani az adatok és vezérlőinformációk átküldése alatt, végül a kapcsolatot le kell bontani. Az LLC CONTROL 1 bitesre változik 13. Ezt nevezik TYPE 2 formátumú 14 LLC PDU-nak. Adatszállító fej: DSAP SSAP CONTROL 1 CONTROL 2 DDDDDDDI/G SSSSSSSC/R N(S) 0 N(R) P/F Supervisory fej: DSAP SSAP CONTROL 1 CONTROL 2 DDDDDDDI/G SSSSSSSC/R 0000 SS 0 1 N(R) P/F Megjegyzés: nem tüntettük fel a fej után következő adatmezőt. A CONTROL mező leírását a szakirodalomban megtalálhatjuk (pl. most csak annyit ennek a sajátosságairól, hogy minden PDU-t egy sorszámmal, pl. Nr(SEND) látnak el, az összeköttetéses kapcsolatot megvalósító LLC protokoll működtetése érdekében. Újra felmerült a kapcsolat nélkül és kapcsolatot megvalósító szolgáltatás kérdése. A kapcsolat orientált szolgáltatások biztonságosabbak az adatvesztés elkerülésében. Ezt a biztonságot sok szerviz információ küldözgetésével érik el, ezért (ugyanolyan minőségű hálózatok esetében) relatíve kisebb a felhasználó által látott adatviteli sebesség, mint a kapcsolat mentes szolgáltatásoknál. A felhasználási terület határozza meg, hogy melyiket célszerű használni. Például folyamatirányítási célú hálózatban jó, ha biztonságos az adatátvitel, viszont egy videokonferencián nem zavaró egy apró képhiba, itt inkább az átviteli sebességen van a hangsúly. Térjünk vissza az LLC PDU adatmezőjéhez! Adatmező: Általában hálózati réteg protokollja (általánosabban az LLC kliense) tölti fel adatokkal, illetve vétel esetén az értelmezi. (Az LLC PDU-t bemutató ábrán például az IP által kezelt adatmezőre utalunk.) Megismételjük, hogy az ETHERNET kártyát nem érdekli, hogy mit ad vagy vesz, egyszerűen szó szerint elküldi azt, amit rábízott az LLC. Az LLC kliensének figyelembe kell vennie, hogy az adott MAC+LLC protokollban mennyi az egy kerettel átvihető adatbájtok száma. Ethernet hálózat esetén ez az ún. Maximum Transmission Units (MTU) az aktuális kerettípustól függően 1500 bájt körül van. A most tárgyalt kerettípus esetén az MTU 1497 bájt. Néhány MAC protokoll és az MTU értéke: MAC protokoll MTU [byte] MAC protokoll MTU [byte] Token Ring ARPANET 100 FDDI 4352 X Ethernet II 1500 ARCNET 508 Ethernet Szabványos minimum 8 12 Ezeket a módszereket később a TCP kapcsán részletesen tárgyaljuk. 13 A vezérlő bájt helyett szó lesz. 14 A típusok (type) az LLC PDU fejére vonatkoznak IV Szarka T.

10 PAD mező: Opcionális mező, az Ethernet keretet a minimális 4 bájtos hosszra egészíti ki. (Tehát a MAC címek, hossz, LLC PDU, PAD, CRC legalább 4 bájtot tegyenek ki.) A most tárgyalt kerettípus esetén is elképzelhető, hogy 43 bájtnál kevesebb adatot, pl. 10 bájtot kell küldeni. Ilyenkor az LLC érzékeli, hogy 10 bájtos a PDU adatmezeje és ennek megfelelően állítja be a hossz jelzést 13-ra (3 LLC fej+ 10 LLC adat). Viszont gondoskodnia kell a PAD mező feltöltéséről, hogy a legrövidebb kerettel kapcsolatos követelményeket kielégítse. Ebben az esetben tehát 33 bájtos PAD mezőt illeszt a PDU adatbájtok után (14 MAC fej+13 LLC PDU+33 PAD+4 CRC). Természetesen a vételi oldalon a hossz mező alapján leválasztják a tölteléket (a PAD-ot) az LCC PDU adatmezőjéről, így nem kerül át a hálózati rétegbe. Elképzelhetőnek tartom azt is, hogy a PAD (Packet Assembler-Disassembler) mezőt az Ethernet kártya automatikusan generálja. A kérdést nem tudtam eldönteni, mert az Ethernet kártya később megismerendő eszközmeghajtó szoftvere eltakarja ezt a problémát a programozó elől. CRC mező a keret épségét ellenőrző bájtsorozat. Adáskor az LLC alréteg a memória x címétől kezdve elhelyezi a küldendő MAC keret teljes tartalmát a NIC által automatikusan generált preamable és CRC mezők kivételével. Ezután parancsot ad az Ethernet adapternek, hogy az előbbi x memória címtől kezdődően n bájtot küldjön a médiára. Amikor a NIC megkezdi az adást, a keret tartalmából a cél címtől kezdve hibaellenőrző kódot generál 15 és az utolsó adatbájt után elküldi mint 4 bájtos értéket. Adás érzékelése esetén a NIC a cél MAC címét vizsgálva eldönti, hogy vennie kell-e a médián érzékelt keretet. Vételkor a NIC az LLC által vételi pufferként megadott y memóriacímtől kezdve a preamble és CRC mező kivételével a teljes keretet elhelyezi. A keret végét a MAC szinten kialakuló adásszünet jelenti, ekkor a vevő ellenőrzi a CRC-t. A vett keretet eldobja, ha hibás a CRC a beérkezett keretben 1. Azt már említettük, hogy Ethernet hálózatban sem a vevő MAC, sem a vevő LLC rétege nem küld az adónak visszajelzést a vétel sikerességéről vagy sikertelenségéről. ETHERNET II keret Ez a változat 3 évvel idősebb mint az IEEE ajánlás, de jelentősége miatt kvázi szabványnak is tekinthető. Egyéb megnevezései: DIX ETHERNET, ill. az eredeti 1982-es ETHERNET II. leírás borítója alapján Blue Book ETHERNET. Preamble 8 MAC cél MAC forrás Protokoll azonosító 2 Adat Látszik, hogy a szabványos LLC fej hiányzik, csak egy protokoll azonosítót tartalmaz a keret. Megalkotói úgy gondolták, hogy hossz információt tartalmazó mezőt, majd a protokollok biztosítanak maguknak az adatmezőben, a protokollra jellemző kereten belül. Protokoll azonosító mező: tartalma mindenképpen nagyobb, mint 1500, ezért ebből a jobb szoftverek felismerik, hogy ETHERNET II típusú kerettel dolgoznak, mert a hossz/típus mező értéke alapján a két keretformátum megkülönböztethető. (Felismerhető, hogy az ETHERNET II-ből kifejlesztett IEEE keretben az IEEE betét DSAP mezője vitte tovább a protokoll azonosító funkcióját a szabványosítás után.) A mező konkrét értékei közül néhány, a XEROX nyilvántartása szerint: PAD x CRC bites AUTODIN II. polinom segítségével készíti. Csak az egyszerűsítés miatt neveztük CRC mezőnek. 1 Fizikailag beolvassa, de logikailag nemlétezőnek tekinti IV Szarka T.

11 000 XNS 001 XNS Address Translation 0800 DOD IP 0801 X.75 internet 0802 NBS internet 0803 ECMA internet 0804 Chaosnet 0805 X.25 Level ARP 0807 XNS Compatibility 081C Symbolics private 0888 Xyplex 0900 Ungermann-Bass net debug 0A00 Xerox PUP 0A01 Xerox PUP Address Translation 0BAD Banyan Systems 0BAF Banyan Echo 1000 Berkeley trailer negotiation Berkeley trailer encapsulation 1234 DCA - Multicast 100 VALID system protocol 1989 Artificial Horizons (dogfight sim.) 3C00-3Com NBP 4242 PCS Basic Block Protocol 4321 THD - Diddle 5208 BBN Simnet Private 000 DNA experimental 001 DNA Dump/Load -MOP- 002 DNA Remote Console -MOP- 003 DNA IV Routing Layer 004 DEC: Local Area Transport 005 DEC: Diagnostics 00 DEC: Customer Use 007 DEC: LAVC 010-3Com 7000 Ungermann-Bass download 7001 Ungermann-Bass NIUs 7002 Ungermann-Bass diagnostic/loopback 7003 Ungermann-Bass 7005 Ungermann-Bass Bridge 7007 OS/9 Microware 7009 OS/9 Net? Sintrom (was LRT) 7030 Racal-Interlan 7031 Prime NTS 7034 Cabletron 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe 800 Nestar 8008 AT&T/Standford 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics 801 Silicon Graphics XNS Nameserver 8019 Apollo DOMAIN 802E Tymshare 802F Tigan 8035 Reverse ARP 803 Aeonic Systems 8037 IPX (Netware) 8038 DEC: bridge 8039 DEC: DSM/DDP 803A DEC: (Argonaut console) 803B DEC: (VAXELN) 803C DEC: NMSV DNA Naming 803D DEC: encryption 803E DEC: distributed time service 803F DEC: LAN Traffic Monitor 8040 DEC: NetBIOS Datagrams 8041 DEC: Local Area System Transport 8042 DEC Unassigned 8044 Planning Research Corp AT&T 8048 DEC: DECamds 8049 ExperData 805B VMTP/RFC C Stanford V Kernel 805D Evans & Sutherland 800 Little Machine 802 Counterpoint Computers 805- UMass. at Amherst 807 Veeco Integrated Automation 808 General Dynamics 809 AT&T 80A Autophon 80C ComDesign 80D Compugraphic Corp. 80E- Landmark Graphics Corp. 807A Matra 807B Dansk Data Elektronic 807C Merit Internodal 807D- Vitalink Communications 8080 Vitalink TransLAN III Mgmt Counterpoint Computers Xyplex 809B AppleTalk (EtherTalk) 809C- Datability 809F Spider Systems 80A3- Siemens-Nixdorf 80C0- DCA: Data Exchange Cluster 80C Pacer Software 80C7 Appplitek Corp. 80C8- Intergraph Corp. 80CD- Harris Corporation 80CF- Taylor Instrument 80D3- Rosemount Corp. 80D5 IBM SNA Service on Ethernet 80DD Varian Associates 80DE- TRFS (Integrated Solutions) 80E0- Allen-Bradley 80E4- Datability 80F2 Retix 80F3 AppleTalk AARP 80F4 Kinetics 80F7 Apollo Computers 80FF- Wellfleet Symbolics 812B Talaris 8130 Waterloo Microsystems 8131 VG Laboratory Systems 8137 Novell NetWare KTI 814C SNMP over Ethernet 814F Technically Elite Concepts 817D XTP 81D Lantastic 8582 Kalpana 8DD IPv 8888 HP LanProb 9000 Loopback Com: XNS Mngmt Com: TCP/IP Mngmt Com: loopback detection AAAA DECNET FF00 BBN VITAL-LanBridge IV Szarka T.

12 Ha a protokoll azonosítót WORD-ben tároljuk, akkor gondoskodnunk kell az alsó és felső bájtok cseréjéről, pl. a 8137H helyett 3781H-t kell egy WORD-ben tárolni! Ez a csere az általunk használt INTEL processzorok esetében szükséges, mert ezekre az ún. kis endian típusú adattárolás jellemző. A kis endian sajátossága, hogy egy több bájtos adatszerkezetnek a legkisebb helyiértékű bájtja kerül az adatszerkezet által elfoglalt memóriaterület legkisebb című bájtjába. A hálózati bájtsorrend nagy endian módon kezeli a szavakat, azaz az alacsonyabb memória címen van a szó nagyobb helyiértékű bájtja. (A MOTOROLA gyártmányú processzorok szintén nagy endian módon tárolják a szavakat, ezért ha APPLE-re fejlesztünk, akkor nincs (ilyen) problémánk, mert a hálózati bájtsorrend megegyezik a hoszt oldali bájtsorrenddel. Elegánsan is megoldható ez a probléma: pl. egy CD-ROM esetén, mindkét alakban rögzítik a vezérlő információkat és lám ezt a médiát mindegyik rendszerben probléma nélkül lehet használni!) Sokat beszéltünk az Ethernet keretekről, hát megnézzünk meg egyet! Ehhez az Analyzer 17 nevű (free) protokoll analizátort használtuk: a segítségével elkaptuk (capture) egy induló W98 által a hálózaton generált kereteket. A 3.-ként elfogott keretet vizsgálgatjuk egy kicsit, amelyet az ARP protokoll bocsájtott a médiára. (A protokollt kétszer megemlíteni ugyan felesleges, de gördülékenyebb a fogalmazás. Az ARP-t egy későbbi fejezetben részletesen megvizsgáljuk, most csak annyit érdemes tudni róla, hogy a hálózati réteg kiegészítő protokollja.) Szóval azt láthatjuk, hogy az általa küldetett keret broadcast célcímet használ, a küldő címével sincs probléma mert unicast jellegű (viszont a megjelenítése inkább egzotikusnak nevezhető mint szabványosnak). A protokollt azonosító word-őt (080H) a memóriában az ún. hálózati bájtsorrendben találjuk meg, nem pedig az Intel-es világban megszokott kis endian system szerint. (Ehhez a word-ön host order to network order konverziót kellett az ARP-nek végeznie. Ezt mi az előzőekben a word-öt alkotó bájtok felcseréléseként adtuk elő.) Az analizátor egyébként Ethertype-Length lehetőségekből indult ki a harmadik mezőnél, de azt tapasztalta, hogy a mező értéke olyan nagy, hogy nem lehet hossz benne, ezért rájön, hogy típust (protokoll azonosítót) tartalmaz a mező. 17 Használatához a következő fejezetben ismertetendő WinPcap Windows-zos packet driver kell IV Szarka T.

13 ETHERNET SNAP (SUBNETWORK ACCESS PROTOCOL) típusú keret NIC generálja LLC generálja LLC PDU (Az LLC kliensétől v. kliensének) MAC fej LLC fej SNAP Preamble 8 Cél Adó Hossz 2 DSAP 1 SSAP 1 CONTROL 1 OUI 3 TYPE 2 ADAT DSAP=AAH SSAP=AAH CONTROL=03H OUI (Organizationally Unique Identifier) mint protokoll gyártója, gazdája=0 18 TYPE= az ETHERNET II. tipusnál megismert protokoll azonosítók. Az IEEE keretben egy kicsit módosult a (LLC) betét kialakítása. Az eredetileg DSAP, SSAP, CONTROL bájtok eredeti szerepe megszünt, tartalmuk fixen a következő: AAH, AAH, 03, amely a SNAP típusú keretet jelzi. A SNAP keret újdonsága az, hogy a fenti 3 bájtot követi egy 5 bájtos protokoll azonosító, az IEEE ben szereplő, effektíve 7 bites azonosító helyett. (Az viszont nem látszik itt, hogy SNAP útválasztási információt is hordozhat, ami az igazi újdonság.) A SNAP keret a fenti 3 bájt tartalma alapján könnyen megkülönböztethető az IEEE IEEE típustól. A protokoll azonosító felső 3 bájtján (OUI) általában 0 van, míg az alsó két bájton az ETHERNET II.-ben megismert protokoll azonosítók találhatók. Pl. AA AA az IP protokoll azonosítója! Pl. AA AA az Appletalk phase II. protokoll azonosítója! Ha a protokoll azonosítót WORD-ben tároljuk, akkor gondoskodnunk kell az alsó és felső bájtok cseréjéről! Aláhúzva láthatjuk a memóriában (és a médián) kialakítandó bájtsorrendet. (Tehát pl. a 0893H helyett 9308H-t kell a WORD-ben tárolni!). NOVELL (RAW) típusú keret A Novell Netware 3.11 verziója előtt a Novell saját IPX/SPX protokollja használta ezt a kerettípust. Van hossz mezője, viszont nincs betétje (nyers RAW), ezért nem alkalmas multiprotokollos működésre és megakadályozza azt is, hogy az IEEE féle keretekkel együtt használják a hálózatot, ugyanis a két keretformátum nehezen különböztethető meg egyértelműen. Kihasználható az, hogy az IPX fejléc első két bájtja feleslegesen van ellenőrző összeg részére fenntartva, mert a MAC alréteg végez hibadetektálást. Ezért az IPX fejléc első két bájtja FFH-FFH tartalmat is adhat a DSAP és SSAP mezőknek, így lehetőség adódik a keretformátum megkülönböztetésére. (A protokoll azonosító hiánya miatt azonban továbbra is csak egy protokoll használatát teszi lehetővé a keret.) Ethernet keretek összefoglalása: Byte Ethernet II Ethernet-SNAP Novell (RAW) IEEE LLC 0-5 Cél cím Cél cím Cél cím Cél cím -11 Forrás cím Forrás cím Forrás cím Forrás cím Prot. azon. (Type) Hossz Hossz Hossz 14 DSAP (fix AAH) DSAP (lényegében a Type) 15 SSAP (fix AAH) SSAP 1 Control (fix 03H) Control-1 17 Organizációs kód (Control-2) 18 (3 byte) Típus (Type) Horváth György, Lanvizs.zip (MEK) 18 Pl C=CISCO LLC gen. PAD x NIC gen. CRC IV Szarka T.

14 A hálózati operációs rendszerek (NOS) által támogatott keretek Itt most azt vizsgáljuk, hogy egy hálózati operációs rendszer melyik másikkal tud hálózati kapcsolatot kialakítani. Ennek szükséges, de nem elégséges feltétele, hogy támogassanak legalább egy közös kerettípust. Keret típus: Novell elnevezése: Cisco elnevezés: Windows elnevezés IEEE LLC Ethernet_ LLC Ethernet Ethernet II. Ethernet_II. ARPA Ethernet II SNAP Ethernet_SNAP 20 SNAP SNAP Novell (RAW) Ethernet_802.3 Novell Ethernet Novell Netware által támogatott keretek és protokollok: Netware 3.11 előtt: [Ethernet 802.3] (RAW) [Ethernet II.] Netware 3.12 től: [Ethernet 802.3] [Ethernet LLC] [Ethernet II.] [Ethernet 802.3] [Ethernet LLC SNAP] IPX/SPX TCP/IP IPX/SPX IPX/SPX és TCP/IP IPX/SPX és TCP/IP és AppleTalk A kliens természetesen mindegyiket támogatja, lásd a NET.CFG load és bind parancsait. Windows alapú hálózatok: TCP/IP protokoll esetén Ethernet II (DIX Ethernet) típusú keret az alapértelmezett. A registryben beállítható SNAP keretek adása is, pl. W2000 esetén: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters alatt létre kell hozni, vagy módosítani kell az ArpUseEtherSNAP bejegyzést, amelynek jellemzői: Value Type: REG_DWORD Boolean Valid Range: 0, 1 (false, true) Default: 0 (false) A paraméter 1-es értéke esetén a TCP/IP adáshoz SNAP típusú Ethernet keretet használ, de vételre továbbra is mindkét keretformátumban képes. NW Link (IPX/SPX kompatibilis Microsoft protokoll) esetén az Ethernet (LLC TYPE1) keret az alapértelmezett, de a protokoll tulajdonságai menüből bármelyik beállítható. NetBEUI protokoll esetén Ethernet (LLC TYPE2) keret használatos. Összefoglalva az eddigieket megállapíthatjuk, hogy az LLC réteg feladata az, hogy a kliens réteg felé egy MAC-tól és annak keretformátumától független, hibamentes adatátviteli szolgáltatást nyújtson a kliens(ek) számára. Az LLC szolgáltatások a MAC alréteg szolgáltatásaira (különböző protokolljaira) épülnek. Az ETHERNET a MAC egyik (CSMA/CD) jellegű realizációja. Az ehhez a MAC protokollhoz használt NIC drájverek általában (pl. IP alatt ) TYPE I. LLC szolgáltatásokat nyújtanak klienseiknek, azaz nyugtázatlan össszeköttetés mentes szolgálatokat. Láttuk viszont, hogy NetBEUI esetén össszeköttetéses szolgálatokat biztosítanak. Megismertük az ETHERNET hálózatokon használatos négyféle MAC keretet, valamint az ezekben használt MAC és SAP jellegű címeket hordozó mezők tartalmát és ezek szerepét. 2. Adatkapcsolati réteg LLC IEEE MAC Fizikai réteg CSMA/CD Token Bus Token Ring 19 DSAP=SSAP=0E0H 20 DSAP=SSAP=0AAH IV Szarka T.

15 Az ETHERNET kártya ellenőrzése Mielőtt az Ethernet interfészt felhasználnánk célszerű ellenőriznünk a NIC(ek) és a kábelezés működőképességét. Ellenőrzéshez hozzunk létre egy minimális hálózatot, pl. két NIC és egy crossover kábel felhasználásával. Tesztelő szoftver műszerként használjuk a NIC telepítőlemezén található setup jellegű programot, pl. RSET8029.EXE, SET2111.EXE. Valószínűleg más néven, de minden hálókártyához kaptunk ilyen programot.... Az általam vizsgált Setup And Diagnostics programok a NIC típusára utaló feliratokat leszámítva a következő módon jelentkeznek be: Ha lekérjük az aktuális beállításokat, a következőket láthatjuk az ábrán: A kártya MAC címe 10 BASE T média csatlakozik a NIC-hez, amely egyébként automatikusan figyeli azt, hogy a csavart érpáras (TP) vagy a koax-os (CX) csatlakozóját veszik-e igénybe. A kártya képes adásra és vételre egy időben. (Full-duplex üzemmód engedélyezett.) A kártya báziscíme az I/O címtartományban 000H Hardver megszakításhoz az IRQ 10 vonalat használja 1 KB-os boot EPROM engedélyezve a kártyán. (Ez tévedésből maradt bekapcsolva egy BIOS bővítő EPROM-mal folytatott kísérlet után.) IV Szarka T.

16 Bizonyos beállítások módosítására lehetőség van: Tesztelhetjük a kapcsolatban érintett hardvereket. Az egyik kártyát állítsuk be válaszadásra a Run Diagnostics/Run Diagnostics On Network/Set Up As Responder menüvel: A többi kártyát állítsuk Initiátor üzemmódba és ellenőrizzük az adást (Tx) és a vételt (Rx): IV Szarka T.

17 Speciális Ethernet keretek Pause Frame (802.3x) Full duplex Ethernet technológiák (FastEthernet, GigabitEthernet) használják adatfolyam szabályozásra (flow control). Pl. számítógép és switch kapcsolatban fordul elő, hogy valamelyik eszköz a vevő pufferének telítettsége miatt pause frame-t küld a linkre, hogy a távolvéget az adásának a szüneteltetésére rávegye : Preamble 8 MAC cél MAC forrás Protokoll azon./hossz 2 OpCode 2 Pause Time 2 MAC cél mindig egy speciális multicast cím: C MAC forrás: a küldő interfész címe Protokoll azonosító: 8808 OpCode: 0001 azaz pause Pause Time: ezen paraméter * 512 bit ideje adja a kért várakozási idő nagyságát. Új pause kerettel a várakozás alatt aktualizálható. Pad: 0 értékű kitöltő oktettek VLAN és kiegészítése a Class of Service (802.1q és 802.1p) A korszerű kapcsolók támogatják VLAN-ok kialakítását. Ennek segítségével már az adatkapcsolati rétegben olyan (virtuális) hálózatok hozhatók létre, amelyek között a forgalom csak routeren keresztül jöhet létre. A kapcsoló hozzáférési pontján beérkező keretet a VLAN információkat hordozó Tag-gel egészíti ki, ezért a keret mérete az eredeti Ethernet szabványban engedélyezettnél hosszabb lesz. Ezek kezeléséhez olyan speciális interfészekre van szükség amelyek támogatják a 802.1q keretformátumot (beágyazást). Számítógépek általában nem találkoznak ilyen keretekkel, mert a kapcsoló a eltávolítja a plusz mezőt a címzetthez érkező keretekből. Ha a számítógépet VLAN-ok közötti forgalom irányítóként üzemeltetik, akkor olyan Ethernet adaptert és operációs rendszert kell használni amely támogatja a VLAN kezelést. Preamble 8 MAC cél MAC forrás Tag 4 Eredeti protokoll azon./hossz 2 PAD 42 Eredeti adatok max 1500 CRC 4 Új CRC 4 A keretbe illesztett Tag tartalmazza a kiegészítő információkat. 4 bájtos méretével nő az eredeti keret hossza, így a keret tartalmának változása miatt az ellenőrző összeg újraszámolása is megtörténik. A Tag részletei: Tagged Frame Type 1 bit 802.1p Priority 3 bit Canonical 1 bit 802.1q VLAN ID 12 bit Tagged Frame Type (Tag Protocol Identifier): 0x8100, 0x9100, 0x9200 értékek valamelyike jelzi, hogy 802.1q és 802.1p jellegű információkat is szállít a keret. A következő 3 mezőből álló csoport a TCI (Tag Control Information): Priority: adatkapcsolati szintű QoS támogatást biztosít: 7: Hálózat vezérlő információk: pl. a RIP, OSPF útválasztási információk,5: Késleltetésre érzékeny adatok: pl. video, hang. 4..1: Adatvesztésre kevéssé érzékeny alkalmazások adatai: pl. FTP 0: a hagyományos best effort szolgáltatás Canonical: Ethernet típusú hálózatokban mindig 0 VLAN ID: 0 csak prioritás szintet rendel a kerethez : érvényes VLAN ID 4095: foglalt azonosító IV Szarka T.

18 Pont-pont kapcsolatok keretformátumai Az előző részben megismertük az üzenszórásos csatornán, pl. az Ethernet hálózatokban használatos kereteket. Pont-pont jellegű kapcsolatban más keretformátumok terjedtek el. HDLC (High-Level Data Link Control) Ez az egyik jelentős protokoll 21 mely összeköttetéses kapcsolatot nyújt. A HDLC a hibajavítást és adatfolyam vezérlést nyugtázással oldja meg. A nyugtázás hatékonysága és az adatfolyam vezérlés érdekében csúszóablakos eljárást használ. A HDLC keretek formátuma (forrás: ): Az eredeti HDLC keret nem tartalmaz protokoll azonosító mezőt, ezért csak egyféle protokoll adatait képes szállítani. Különböző továbbfejlesztések jelentek meg, pl. a CISCO által kifejlesztett (és a routerekben alkalmazott) változat már képes többféle hálózati rétegbeli protokoll szállítására. A HDLC-hez hasonló, de más technológiákhoz optimalizált protokollok ( ): HDLC: High-level Data Link Control (ISO) SDLC: Synchronous Data Link Control (IBM) LAPx: Link Access Procedure (CCITT ITU T) LAPB: Link Access Procedure Balanced LAPD: Link Access Procedure on D channel (ISDN) LAPF: Link Access Procedure FR (Frame Relay) LAPM (Link Access Procedure for Modems) PPP (Point to Point Protocol) Szintén a HDLC továbbfejlesztésével keletkezett. Szolgáltatásai miatt az Interneten elterjedten alkalmazzák. Két alprotokollból áll: LCP: feladata a pont-pont összekötés létrehozása az adatkapcsolati réteg szintjén. A kapcsolatot konfigurálja és teszteli. Egyéb szolgáltatásokat is megvalósíthat: Hitelesítés (pl. PAP, CHAP) Tömörítés Hibafelismerés Multilink 22 PPP PPP visszahívás Kapcsolat megszakítása NCP: feladata a különböző hálózati protokoll (pl. IP) beágyazása és konfigurálása, hogy a PPP kapcsolaton átvihető legyen az adatcsomag. Minden L3 protokollhoz külön hálózati vezérlő protokoll tartozik, pl. az IP-hez IPCP, amelynek feladata pl. az IP cím beállítása a végponton vagy a DNS szerver címének megadása, stb vehok.uni-pannon.hu/~brios/jegyzet/szamitogep%20halozatok%20jegyzet/x25.doc 22 Pl. az ISDN BRI két B csatornájának nyalábolása (akár dinamikusan is) terhelésmegosztás céljából IV Szarka T.

19 Egy lehetséges forgatókönyv a PPP működésére A PPP először a tárcsázó jellegű démont indítja, amely létrehozza a fizikai szintű kapcsolatot a két végpont között. Amikor a modemek konnektálnak akkor indul az LCP szintű egyeztetés. Ehhez mindként végpont LCP kereteket küld terhelési és egyeztetési céllal. Kezdetben a PPP Link-Dead állapotú. A modemek konnektálása után Link-Establishment állapotba kerül. Ezután konfigurációs kereteket küldözgetnek. Ha ez sikeres volt, akkor LCP-Open állapotba kerül a PPP. Ezt követi az opcionális azonosítási (általában PAP vagy CHAP) folyamat. Végül az NCP egyeztetési folyamat után használható lesz a kapcsolat. A kapcsolat bármikor megszakítható LCP vagy NCP segítségével, ill. megszakad a vivő elvesztésekor, azonosítási hibánál, a link minőségének romlásakor vagy huzamosabb ideig inaktív link esetén. A PPP kapcsolat kiépítésének fázisai: forrás: A továbbiakban mi az authentication (hitelesítés) opcióval foglalkozunk. A hitelesítés célja, hogy a linken összeköttetést létrehozni szándékozó készülékek egyike (vagy mindegyike) tudjon arról, hogy kivel épít ki (és tart fenn) kapcsolatot. Pl. egy Internet Szolgáltató ezzel azonosítja a felhasználót, mielőtt szolgáltatna számára. PAP (Password Authentication Protocol) A PPP Link-Establishment állapotát érzékelve kapcsolatot kezdeményező (initiator) végpont a felhasználói nevet és jelszót egyszerű nyilt szövegként küldi át a létrejött LCP linken a védett végpontnak (authentcator), ezzel egy alacsony fokú védelmet nyújtva a jelszó lehallgatása, ellopása vagy visszajátszása ellen. A küldést addig ismétli, amíg a hitelesítést jelző nyugta meg nem érkezik vagy a link meg nem szakad, pl. a sikertelen hitelesítés miatt. A hitelesítés csak egyszer, a PPP kapcsolat kiépítési fázisában történik meg. A PAP konfigurálása CISCO routeren Első lépés: a védendő pl. R1 router helyi hitelesítési adatbázisába felvesszünk (legalább) egy felhasználónevet és a hozzátartozó jelszót, de közben ügyeljünk arra, hogy a kis- és nagybetűket a rendszer megkülönbözteti. Több felhasználó és jelszava is elhelyezhető az adatbázisban, de egy felhasználói névhez csak egy jelszó rendelhető. A későbbiekben majd az ebben az adatbázisban megtalálható valamelyik párost használó protokoll vagy felhasználó férhet hozzá a router bizonyos védett szolgáltatásaihoz. Ezt az adatbázist a router a különböző hitelesítési feladatok (pl. soros-, ill. konzol porton, stb. végzett hitelesítések) alkalmával fogja használni. Tehát egy felhasználó és jelszava: R1(config)#username fh1_név password fh1_jelszó IV Szarka T.

20 Második lépés: a pont-pont kapcsolathoz tartozó routerek soros interfészein PPP beágyazást írunk elő. Az interfészek egyéb beállításait (pl. IP cím, netmaszk, stb) sem hanyagoljuk el, de itt azokat nem részletezzük: R1(config-if)#encapsulation ppp R2(config-if)#encapsulation ppp Harmadik lépés: a védendő router interfészen előírjuk az alkalmazandó hitelesítési eljárást. A következő paranccsal megadhatjuk a használandó hitelesítési eljárást vagy eljárások esetén azok sorrendjét: R1(config-if)#ppp authentication {chap pap chap pap pap chap} Most konkrétan: R1(config-if)#ppp authentication pap Negyedik lépés: az itt következő parancsra csak azért van szükség, mert eltérünk az alapértelmezés szerinti bizonságos CHAP hitelesítő eljárástól. A hitelesítendő routeren (tehát azon amelyik igazolja magát) beállítjuk, hogy CHAP helyett PAP eljárást használjon és egyben az eljárás során használandó felhasználói nevet és jelszót is megadjuk. Fontos, hogy ezek azonosak legyenek az R1 hitelesítési adatbázisában már korábban tárolt értékekkel: R2(config-if)#ppp pap sent-username fh1_név password fh1_jelszó CHAP (Challenge Handshake Authentication Protocol) A PPP Link-Establishment állapotának elérését érzékelve a védett (hitelesítő) router egy kihívást (challenge) küld a kezdeményezőnek. (Az eljárás megköveteli, hogy mindkét résztvevő ugyanazt a jelszót használja az azonosításra.) A kihívásban szerepel egy számsorozat és a hitelesítő router neve. A kezdeményező megkeresi a hitelesítő nevéhez tartozó jelszót, majd ebből és a számsorozatból képez egy hash értéket 23 (kivonatot), amit visszaküld a hitelesítőnek. A hitelesítő a számsorozat és a kezdeményezőhöz tartozó jelszó alapján maga is számított egy kivonatot. A hitelesítő a két kivonatot összehasonlítja és ha megegyezik, akkor hitelesítettnek tekinti a kezdeményezőt. Későbbiekben a hitelesítő a PPP kapcsolat alatt bizonyos időközönként majd megismétli a kihívási folyamatot, de mindig másik számsorozattal. Ez az eljárás biztosítja, hogy a link lehallgatásával, majd a válasz visszajátszásával sem lehet megtéveszteni a hitelesítőt. Figyeljük meg, hogy a jelszó még titkosított formában sem jelenik meg a linken. A CHAP konfigurálása CISCO routeren, amely az R1 router védelmét mutatja be Első lépésként mindkét routeren létrehozzuk a hitelesítési adatbázist. Most fontos, hogy felhasználói névként a szomszédos router nevét adjuk meg, mert az eljárásban (alap beállítások mellett) minden router a saját hoszt nevét küldi el felhasználói névként. A bevezetőben szereplő okokból azonos jelszót kell a routerekhez rendelni: R1(config)#username R2 password közös_jelszó R2(config)#username R1 password közös_jelszó Második lépés: a pont-pont kapcsolathoz tartozó routerek soros interfészein PPP beágyazást írunk elő. Az interfészek egyéb beállításait (pl. IP cím, netmaszk, stb) sem hanyagoljuk el, de azokat most sem részletezzük: R1(config-if)#encapsulation ppp R2(config-if)#encapsulation ppp 23 Egy olyan speciális függvénnyel dolgozik, amelynek értékeit megfigyelve nagyon költséges lenne meghatározni, hogy milyen függvény argumentum hatására jött létre a függvény értéke. Ez még akkor is igaz, ha a link lehallgatásával hozzájutunk az argumentum egyik részéhez, a kihívásban szereplő számsorozathoz! IV Szarka T.