Az adatkapcsolati réteg

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG

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 802.3 (CSMA/CD) szerinti MAC protokoll és az IEEE 802.2 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 802.2 ajánlás megvalósítása. Az IEEE 802.2 szerint az LLC alréteg nyújt (MAC technológia független) szolgáltatásokat1 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 protokollt2 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 adatblokkot3 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.

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) 1

2009. IV. 15.

1

Szarka T.

HÁLÓZATOK


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 SAP4 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

SAP1

LLC PDU IP-nek

SAP2

LLC PDU Stb.-nek

LLC PDU ARP-nek

SAPn

SAP1

LLC PDU IP-től

SAP2

LLC (≈ NIC driver)

LLC

MAC (≈ a NIC beépített intelligenciája)

MAC

Fizikai réteg (a NIC)

Fizikai réteg

LLC PDU Stb.-től

SAPn

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.

2009. IV. 15.

2

Szarka T.

HÁLÓZATOK


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

2009. IV. 15.

3

Szarka T.

HÁLÓZATOK


IEEE 802.3 típusú Ethernet keret, 802.2 „LLC betéttel” NIC generálja Preamble 8

LLC generálja

Cél MAC címe 6

MAC fej Adó MAC címe 6

LLC PDU (Az LLC kliensétől v. kliensének) LLC fej LLC adat Hossz DSAP SSAP CONTR ADAT 2 1 1 1 0…1497

LLC gen.

NIC gen.

PAD CRC x 4

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ő 56 bit tartalma: 10101010, majd az utolsó 8 bit5 10101011, í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 (6 bájt): első megközelítésben minden Ethernet kártyának 6 bájtos egyedi címe van. A címkiosztás XEROX által központosított módszere elvileg garantálja6, 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 00:00:0E 00:00:10 00:00:15 00:00:1A 00:00:1D 00:00:21 00:00:23 00:00:2A 00:00:3D 00:00:46 00:00:4B 00:00:51 00:00:55 00:00:5D 00:00:61 08:00:0A

BBN Fujitsu Sytek/Hughes LAN Systems Datapoint AMD ? Cabletron SC&C ABB TRW ATT Bunker Ramo APT Hob Electronic AT&T RCE Gateway IBM

00:00:0C 00:00:0F 00:00:11 00:00:18 00:00:1B 00:00:20 00:00:22 00:00:29 00:00:3C 00:00:44 00:00:49 00:00:4F 00:00:52 00:00:5A 00:00:5E 00:00:62 00:AA:00

Cisco NeXT Tektronics Webster Novell/Eagle Tech. Data Industrier AB Visual Technology IMC Auspex Castelle Apricot Logicraft ODS SK/Xerox IANA Honeywell 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 6 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 sorrendben7 és bitenként részletezve: 0. 1. 2. 23. 24. 47. 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).

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. 5 6

2009. IV. 15.

4

Szarka T.

HÁLÓZATOK


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: 01 00 0C CC CC CC • Bridge Spanning Tree: 01 80 C2 00 00 00 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 (224.0.0.1.239.255.255.254) 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.

2009. IV. 15.

5

Szarka T.

HÁLÓZATOK


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 (01-00-5E-00-00-00...01-005E-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 239.192.1.2 csoportcímet használó alkalmazások a következő MAC címet rögzítik a NIC-ben: 01-00-5E-C0-01-02. 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ő: (6 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. 1518 bájt, ill. min. 64 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 43..1497 közötti lehet9: Mező: Méret (bájt): MAC cél 6 MAC küldő 6 Hossz 2 LCC fej 3 CRC 4 Összesen 21 A táblázat a 802.3 keretben elhelyezett 802.2 (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 802.2 (LLC)) szerint TYPE 110 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 DSAP 1 bájt

LLC fejléc SSAP CONTROL 1 bájt 1 bájt

LLC adat Adatok (pl. IP fejléc +adatok(TCP fejléc + adatok) 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.) A később bemutatandó más típusú Ethernet keretek esetében az LLC adatmező mérete ettől eltérő is lehet. 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. 9

10

2009. IV. 15.

6

Szarka T.

HÁLÓZATOK


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 hoszton11 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) 06 ARPANET Internet Protocol (IP) 08 SNA 0C SNA 0E PROWAY (IEC955) Network Management & Initialization 42 IEEE 802.1 Bridge Spannning Tree Protocol 4E EIA RS-511 Manufacturing Message Service 7E ISO 8208 (X.25 over IEEE 802.2 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.

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.) 11

2009. IV. 15.

7

Szarka T.

HÁLÓZATOK


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 SSSSSSS0 000 0 00 1 1 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 DDDDDDDI/G

SSAP SSSSSSS0

CONTROL 101 0 11 1 1

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 DDDDDDDI/G

SSAP SSSSSSS1

CONTROL 101 0 11 1 1

FORMAT XXXXXXXX

CLASS 000YYYYY

WINDOW ZZZZZZZ0

+

XXXXXXXX=10000001 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=0000000 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 DDDDDDDI/G SSSSSSSC/R 111 0 00 1 1

Adatbájtok

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.

2009. IV. 15.

8

Szarka T.

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG IEEE 802.2 (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ésre12. 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 16 bitesre változik13. Ezt nevezik TYPE 2 formátumú14 LLC PDU-nak. Adatszállító fej: DSAP SSAP DDDDDDDI/G SSSSSSSC/R Supervisory fej: DSAP SSAP DDDDDDDI/G SSSSSSSC/R

CONTROL1 N(S) CONTROL1 0000 SS 0

0

CONTROL2 N(R)

P/F

1

CONTROL2 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. http://protocols.com), 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 Token Ring FDDI Ethernet II Ethernet 802.3

MTU [byte] 17914 4352 1500 1497

MAC protokoll ARPANET X.25 ARCNET Szabványos minimum

MTU [byte] 1006 576 508 68

Ezeket a módszereket később a TCP kapcsán részletesen tárgyaljuk. A vezérlő bájt helyett szó lesz. 14 A típusok (type) az LLC PDU „fejére” vonatkoznak. 12 13

2009. IV. 15.

9

Szarka T.

HÁLÓZATOK


PAD mező: Opcionális mező, az Ethernet keretet a minimális 64 bájtos hosszra egészíti ki. (Tehát a MAC címek, hossz, LLC PDU, PAD, CRC legalább 64 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ál15 é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 keretben16. 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 802.3 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 6

MAC forrás 6

Protokoll azonosító 2

Adat 46-1500

PAD x

CRC 4

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 802.3 keretben az IEEE 802.2 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:

15 16

32 bites AUTODIN II. polinom segítségével készíti. Csak az egyszerűsítés miatt neveztük CRC mezőnek. Fizikailag beolvassa, de logikailag nemlétezőnek tekinti.

2009. IV. 15.

10

Szarka T.

HÁLÓZATOK 0600 0800 0802 0804 0806 081C 0900 0A01 0BAF 10011600 3C004321 6000 6002 6004 6006 60107001 7003 7007 70207031 8003 8005 8008 8013 8015 8019 802F 8036 8038 803A 803C 803E 8040 8042 80468049 805C 8060 80658068 806A 806D 807A 807C 8080 8088809C80A380C6 80C880CF80D5 80DE80E480F3 80F7 81078130 8137 814C 817D 8582 8888 9001 9003 FF00

XNS DOD IP NBS internet Chaosnet ARP Symbolics private Ungermann-Bass net debug Xerox PUP Address Translation Banyan Echo Berkeley trailer encapsulation VALID system protocol 3Com NBP THD - Diddle DNA experimental DNA Remote Console -MOPDEC: Local Area Transport DEC: Customer Use 3Com Ungermann-Bass NIUs Ungermann-Bass OS/9 Microware Sintrom (was LRT) Prime NTS Cronus VLN HP Probe AT&T/Standford Silicon Graphics diagnostic Silicon Graphics Apollo DOMAIN Tigan Aeonic Systems DEC: bridge DEC: (Argonaut console) DEC: NMSV DNA Naming DEC: distributed time service DEC: NetBIOS Datagrams DEC Unassigned AT&T ExperData Stanford V Kernel Little Machine UMass. at Amherst General Dynamics Autophon Compugraphic Corp. Matra Merit Internodal Vitalink TransLAN III Mgmt Xyplex Datability Siemens-Nixdorf Pacer Software Intergraph Corp. Taylor Instrument IBM SNA Service on Ethernet TRFS (Integrated Solutions) Datability AppleTalk AARP Apollo Computers Symbolics Waterloo Microsystems Novell NetWare SNMP over Ethernet XTP Kalpana HP LanProb 3Com: XNS Mngmt 3Com: loopback detection BBN VITAL-LanBridge

2009. IV. 15.

ADATKAPCSOLATI RÉTEG 0601 0801 0803 0805 0807 0888 0A00 0BAD 1000 1234 1989 4242 5208 6001 6003 6005 6007 7000 7002 7005 7009 7030 7034 8004 8006 8010 8014 8016 802E 8035 8037 8039 803B 803D 803F 8041 8044 8048 805B 805D 8062 8067 8069 806C 806E807B 807D8081809B 809F 80C080C7 80CD80D380DD 80E080F2 80F4 80FF812B 8131 8139814F 81D6 86DD 9000 9002 AAAA

11

XNS Address Translation X.75 internet ECMA internet X.25 Level 3 XNS Compatibility Xyplex Xerox PUP Banyan Systems Berkeley trailer negotiation DCA - Multicast Artificial Horizons (dogfight sim.) PCS Basic Block Protocol BBN Simnet Private DNA Dump/Load -MOPDNA IV Routing Layer DEC: Diagnostics DEC: LAVC Ungermann-Bass download Ungermann-Bass diagnostic/loopback Ungermann-Bass Bridge OS/9 Net ? Racal-Interlan Cabletron Cronus Direct Nestar Excelan Silicon Graphics network games Silicon Graphics XNS Nameserver Tymshare Reverse ARP IPX (Netware) DEC: DSM/DDP DEC: (VAXELN) DEC: encryption DEC: LAN Traffic Monitor DEC: Local Area System Transport Planning Research Corp. DEC: DECamds VMTP/RFC-1045 Evans & Sutherland Counterpoint Computers Veeco Integrated Automation AT&T ComDesign Landmark Graphics Corp. Dansk Data Elektronic Vitalink Communications Counterpoint Computers AppleTalk (EtherTalk) Spider Systems DCA: Data Exchange Cluster Appplitek Corp. Harris Corporation Rosemount Corp. Varian Associates Allen-Bradley Retix Kinetics Wellfleet Talaris VG Laboratory Systems KTI Technically Elite Concepts Lantastic IPv6 Loopback 3Com: TCP/IP Mngmt DECNET

Szarka T.

HÁLÓZATOK


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 (0806H) 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.

2009. IV. 15.

12

Szarka T.

HÁLÓZATOK


ETHERNET SNAP (SUBNETWORK ACCESS PROTOCOL) típusú keret NIC generálja

LLC generálja

MAC fej Preamble Cél Adó Hossz 8 6 6 2

DSAP 1

LLC PDU (Az LLC kliensétől v. kliensének) LLC fej SNAP SSAP CONTROL OUI TYPE 1 1 3 2

LLC gen. ADAT 0…1492

NIC gen.

PAD CRC x 4

DSAP=AAH SSAP=AAH CONTROL=03H OUI (Organizationally Unique Identifier) mint protokoll „gyártója”, gazdája=018 TYPE= az ETHERNET II. tipusnál megismert protokoll azonosítók. Az IEEE 802.3 keretben egy kicsit módosult a 802.2 (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 802.2-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 802.3+IEEE 802.2 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 03 00 00 00 08 00 az IP protokoll azonosítója! Pl. AA AA 03 00 00 00 08 93 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 802.3 (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 802.2 betétje (nyers≈RAW), ezért nem alkalmas multiprotokollos működésre és megakadályozza azt is, hogy az IEEE 802.3 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 0-5 Cél cím 6-11 Forrás cím 12-13 Prot. azon. (Type) 14 15 16 17 18 19 20-21 Horváth György, Lanvizs.zip 18

Ethernet-SNAP Cél cím Forrás cím Hossz DSAP (fix AAH) SSAP (fix AAH) Control (fix 03H) Organizációs kód (3 byte)

Novell 802.3 (RAW) Cél cím Forrás cím Hossz

IEEE 802.3 + LLC Cél cím Forrás cím Hossz DSAP (lényegében a Type) SSAP Control-1 (Control-2)

Típus (Type) (MEK)

Pl. 00 00 0C=CISCO

2009. IV. 15.

13

Szarka T.

HÁLÓZATOK


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: IEEE 802.3+802.2 LLC Ethernet II. 802.3 SNAP Novell 802.3 (RAW)

Novell elnevezése: Ethernet_802.219 Ethernet_II. Ethernet_SNAP20 Ethernet_802.3

Cisco elnevezés: LLC ARPA SNAP Novell

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 802.2 LLC] [Ethernet II.] [Ethernet 802.3] [Ethernet 802.2 LLC SNAP]

Windows elnevezés Ethernet 802.2 Ethernet II SNAP Ethernet 802.3

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ó 802.3 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 802.3 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 802.2 (LLC TYPE1) keret az alapértelmezett, de a „protokoll tulajdonságai” menüből bármelyik beállítható. NetBEUI protokoll esetén Ethernet 802.2 (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 MAC

1. Fizikai réteg 19 20

IEEE 802.2 802.3

802.4

802.5

CSMA/CD

Token Bus

Token Ring

DSAP=SSAP=0E0H DSAP=SSAP=0AAH

2009. IV. 15.

14

Szarka T.

HÁLÓZATOK


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 6000H • Hardver megszakításhoz az IRQ 10 vonalat használja • 16 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.)

2009. IV. 15.

15

Szarka T.

HÁLÓZATOK


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):

2009. IV. 15.

16

Szarka T.

HÁLÓZATOK


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 6

MAC forrás 6

Protokoll azon./hossz 2

OpCode 2

Pause Time 2

PAD 42

CRC 4

MAC cél mindig egy speciális multicast cím: 01-80-C2-00-00-01 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 6

MAC forrás 6

Tag 4

Eredeti protokoll azon./hossz 2

Eredeti adatok max 1500

Ú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 802.1p Priority Canonical 802.1q VLAN ID 16 bit 3 bit 1 bit 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 • 6,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 1..4094: érvényes VLAN ID 4095: foglalt azonosító

2009. IV. 15.

17

Szarka T.

HÁLÓZATOK

ADATKAPCSOLATI RÉTEG 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 protokoll21 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: www.linuxvilag.hu/content/files/cikk/44/cikk_44_65_68.pdf ): 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 (http://bmf.hu/users/beinschrothj/Infokomm_halozatok/):

• • • • • • •

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 Multilink22 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. www.linuxvilag.hu/content/files/cikk/44/cikk_44_65_68.pdf 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. 21

2009. IV. 15.

18

Szarka T.

HÁLÓZATOK


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: http://www.tcpipguide.com/free/t_PPPLinkSetupandPhases.htm

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ó

2009. IV. 15.

19

Szarka T.

HÁLÓZATOK


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éket23 (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

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! 23

2009. IV. 15.

20

Szarka T.

HÁLÓZATOK


Végül harmadik lépésként a védendő routeren beállítjuk az alkalmazandó hitelesítő eljárást: R1(config-if)#ppp authentication chap Megjegyzés: az előző példákban csak a link egyik végpontján található routert védte egy adott hitelesítő eljárás. Természetesen az előbbi parancsok felhasználásával mindkét végpont védelme megoldható. A PPP beágyazás és a hitelesítés vizsgálata Megvizsgáljuk, hogy a soros interfészhez tartozó linken milyen állapotban van az LCP és az aktuális NCP (részlet a válaszból): R1#show interfaces serial 2/0 Serial2/0 is up, line protocol is up (connected) Hardware is HD64570 Internet address is 192.168.1.1/24 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) LCP Open Open: IPCP, CDPCP

Mit szállítanak a PPP csomagok (részlet): R1#debug ppp packet

Serial2/0 PPP: I pkt type 0xc021, datagramsize 104 Serial2/0 PPP: O pkt type 0xc021, datagramsize 104 Serial2/0 PPP: I pkt type 0xc223, datagramsize 104 Serial2/0 PPP: O pkt type 0xc223, datagramsize 104 Serial2/0 PPP: I pkt type 0x0207, datagramsize 104 Serial2/0 PPP: O pkt type 0x0207, datagramsize 104

0xc021: LCP 0xc223: CHAP 0x0207:CDP

2009. IV. 15.

21

Szarka T.

Az adatkapcsolati réteg

Recommend Documents