A hálózati réteg Szarka T.

Átírás

1 A hálózati réteg Röviden ismételjük át az eddig tanultakat, de érdekesség képen most egy programozó szempontjából. A számítógép hálózatok talán leggyakoribb alkalmazási célja az, hogy egymástól távoli alkalmazói programok (és ezeken keresztül a felhasználók) adatokat cseréljenek egymással. Tudjuk, hogy a gépek közötti az adatmozgatás csak bonyolult programok segítségével oldható meg. A bonyolultság akkor válik áttekinthetővé, ha az adatátvitelt mint komplex feladatot tipikus részfeladatokra bontjuk. A részfeladatokra bontásra több megoldást is kidolgoztak, pl. DoD TCP/ modell, ISO OSI modell, stb. Ezekben a modellekben a részfeladatok rétegekben különülnek el egymástól. Egy adott réteg feladatait bizonyos protokollok szerint eljárva célszerű megoldani. A feladat gyakorisága miatt kialakítottak az operációs rendszerekben (OS) egy hálózati alrendszert 1, ami az egyes alkalmazások helyett megvalósítja a tipikus hálózati protokollokat. Az Alkalmazás I. az adatkapcsolati réteg elérését biztosító packet- (vagy NDIS) driverre támaszkodva képes MAC keretekbe foglalt adatokat mozgatni a saját számítógépe és más (MAC címmel) meghatározott készülék(ek) között. Az Alkalmazás I. eközben nem foglalkozik pl. a keretezés, a hibadetektálás vagy a közeghozzáférési protokollok (pl. CSMA/CD) kérdéseivel. Korlátot pl. akkor érzékel az Alkalmazás I. fejlesztője, ha egy másik hálózatban lévő géppel szeretne kapcsolatba lépni, mert az egyes (al)hálózatokat összekapcsoló routerek nem a MAC cím, hanem az cím alapján végeznek forgalom irányítást, azaz továbbítanak csomagokat. Korlátozhatja ilyenkor a fejlesztőt az is, hogy az adó által elküldött üzenetek megérkezését semmi sem garantálja, a fejlesztőnek kell az esetleg elveszett üzenetek érzékeléséről (szükség esetén pótlásáról) gondoskodnia. Ha az előbbi a hiányosságokat szeretnénk megszüntetni, akkor vizsgáljuk meg az OSI modellt, hogy milyen rétegek protokolljaival bővítse a programját. OSI modell TCP/ modell Tehát az Alkalmazás I.-ben a programozó lemondott a hálózati és szállítási réteg protokolljainak használatáról (az OS-ben meglévőt nem használja, saját implementációt pedig nem írt), ezért nincs esélye arra, hogy hálózatok között generáljon forgalmat és összeköttetéses 2 kapcsolatra építse az alkalmazását. Az Alkalmazás II.-ben a programozó beépített a programjába hálózati és szállítási rétegbe tartozó rutinokat. Az ábrából nem derül ki, hogy milyen protokollokat implementált a 3. és 4. rétegben. Egy kísérletező és ráérő programozóról elképzelhető, hogy a már meglévők helyett saját, pl. TCP/ rutinokat írjon, bár gyakorlati haszna ennek a rendszer alapos megértésén kívül nemigen lenne. Elképzelhető az is, hogy saját protokollt fejleszt ki a hálózati és a szállítási réteg számára. Ha feltételezzük azt, hogy ezek egyik ismert protokollal sem kompatíbilisak, akkor csak saját hálózataiban működnek az adott protokollokat használó alkalmazásai. 1 Pl. WINDOWS, ill. LINUX esetén a kernel része. 2 Csak a hálózaton belüli üzenetek garantált megérkezéséért tehet lépéseket azzal, hogy az LLC rétegben TYPE I-helyett TYPE II jellegűre cseréli a protokollt. Ennek érdekében olyan LLC szintű rutinokat kell használnia, amelyek az adó és vevő között összeköttetéses kapcsolatot valósítanak meg Szarka T.

2 Az Alkalmazás III. kapcsán már egy tipikus esetet láthatunk. A programozó felhasználta az operációs rendszer TCP/ rutingyűjteményét és ennek a szolgáltatásaira építette rá az alkalmazását 3. A továbbiakban mi is a TCP/ 4 protokoll családot vizsgáljuk, amely az Internet hivatalos protokollja és elterjedt a helyi hálózatokban is. A TCP/ tervezésekor négy rétegbe sorolták a hálózati alrendszer szolgáltatásait. Az alsó három réteg realizációját általában az operációs rendszer biztosítja, míg az alkalmazási rétegben a hálózati alkalmazásokat megvalósító programokat találjuk: TELNET, FTP, stb. Ezeket az operációs rendszerrel kapjuk (mint pl. a HTTP klienst azaz WEB böngészőt), vagy más forrásból kell beszerezni. A TCP/ protokoll verem legfontosabb protokolljai: : Internet Protocol. Kapcsolat nélküli (connectionless) datagram továbbító protokoll, amely változó méretű adatcsomagok hálózaton belüli vagy hálózatok közötti átviteléhez használható. A kapcsolat nélküliség azt jelenti, hogy nincs kiegészítő információ forgalom a küldő és címzett között a csomag megérkezéséről vagy elvesztéséről, ezért nem garantálja a csomagok megérkezését, sorrendjének helyeségét, késleltetését. A szolgáltatás minősége (QoS) best-effor delivery jellegű, azaz legjobb tudása szerint kézbesít, tehát az adott pillanatban szabad erőforrások függvényében biztosítja a szolgáltatást. TCP: Transmission Control Protocol. A hálózat két csomópontja között kapcsolat orientált megbízható adatmozgatást tesz lehetővé. A kapcsolat orientáltságot az biztosítja, hogy a végpontok között az adatokon kívül azok nyilvántartását támogató szerviz információ is továbbításra kerül UDP: User Datagram Protocol. A TCP-vel ellentétben egy kapcsolatnélküli (connectionless) protokoll, egyszerű csomagszolgáltatást biztosít. ICMP: Internet Control Message Protocol. Például az használja forgalmi helyzetjelentések (pl. hibajelzések) továbbítására. IGMP: Internet Group Management Protocol. Egy LAN gépei használják, hogy bejegyezzék magukat egy csoportba, pl. multicast című csomagok küldéséhez. ARP: Address Resolution Protocol. Feladata az címekhez tartozó MAC címek meghatározása. A MAC címekre a keretek továbbításakor lehet szükség. RARP: Reverse ARP. A MAC címhez tartozó címet határozza meg. Összefoglalásként nézzük meg a Windows 2000 hálózati alrendszerének felépítését és a különböző hálózati modelleket. A hálózati és transzport rétegekbe illeszkedő protokollok használatával, az alkalmazások arra is alkalmassá váltak, hogy akár hálózatok közötti kommunikációt is végezzen, a LAN-on belüli kommunikáció mellett. A szállítási rétegben található TCP olyan szerepet tölt be a hálózatok közötti kommunikációban, mint a LAN-on belüli összeköttetésben az LLC alrétegben az LLC TYPE II protokoll. Az összeköttetés-mentes protokollokat vizsgálva pedig az UDP és LLC TYPE I hasonlítható össze. 3 Megfigyelhető a TCP/ protokoll stack L4-L1 részének tartalma: TCP--LLC TYPE I.-CSMA/CD 4 Egykori megrendelője a Department of Defense alapján gyakran DoD TCP/ néven említik Szarka T.

3 Internet Protocol () bevezetés Az L3-ban üzemelő gyakorlatilag bármilyen fizikai és adatkapcsolati réteg (L1 és L2) felett képes távoli számítógépek közötti adatátvitelre, amely során a protokoll által használt kétszintű logikai címmel ( címmmel) biztosítja a hálózatok és a hálózati csomópontok címezhetőségét. Két fő szolgáltatása a fregmentálás (ezt később részletezzük) és az útválasztás. Az útválasztás feladata, hogy az egyes adatcsomagok cél felé vezető útjának következő szakaszát kijelölje. Ez a szakasz általában a következő útválasztóig tart, illetve az utolsó útválasztó már a címzetthez továbbítja a csomagot. Az útválasztás a csomag címzettjének logikai címét vizsgálja és csomag útvonalában érintett minden olyan hálózati készüléken lejátszódik, amelyikben legalább az L1-L3 rétegek szolgáltatása implementálva van. (Ezek tipikusan a számítógépek vagy más (cél)számítógépek: router, kamera, nyomtató, telefon, stb). Az útválasztás alatt általában azt a folyamatot értjük, ami egy eszközön akkor játszódik le, amikor egy interfészére olyan csomag érkezik, amelynek nem ő a címzettje. Ez a folyamat meghatározza, hogy a csomagot melyik interfészen kell továbbküldeni, más szavakkal melyik interfészre kell kapcsolni 5. (Az egy interfésszel rendelkező készülékeken is történik útválasztás, még ha nem is olyan látványos mint egy routeren.) Az útválasztó természetesen az L1, L2 szolgáltatásaira, pl. ki-és bekeretezésre is támaszkodik. A csomag továbbküldéséhez használandó interfész kiválasztása alapvetően az ún. routing táblára épül. A routing tábla tartalmát a hálózat felépítésének ismeretében kell meghatározni. Ilyen az ismeretekkel a rendszergazda és/vagy az mellett működő, ún. irányító (útválasztó) protokollok rendelkeznek, így ezek feladata a routing tábla karbantartása. Az előbbiek miatt az az ún. irányított (irányítható) protokollok közé tartozik. Szolgáltatása (amit általában L4-nek nyújt) az, hogy az általa kezelt adategységet az ún. csomagot képes egy tetszőleges hálózat tetszőleges pontjára eljuttatni. Ez a szolgáltatás megbízhatatlan, összeköttetés mentes jellegű, ami azt jelenti, hogy a csomag továbbítása közben a ugyan a legjobb tudása szerint jár el, de nem garantálja azt, hogy a csomag célba is ér. (Ekkor még pl. a csomagok sorrend helyességét nem is említettem). Ha egy adott alkalmazásnak megbízható kapcsolatra van igénye, akkor az -re támaszkodó TCP-t kell használnia, mert az gondoskodik a csomagok helyes sorrendjéről vagy az esetleg elveszett csomagok pótlásáról (ez külön fejezet témája lesz). Az csomag ún. datagram, azaz olyan adategység amiben megtaláljuk a küldő és a címzett () címét. Az datagram (csomag) általában: fejléc adatok (pl. TCP szegmens) Ha az csomag által szállított adatmezőt is részleteznénk, akkor például ezt láthatnánk: LLC fej fejléc TCP fejléc TCP adatok Látható, hogy az L3 is becsomagolja (encapsulation) az L4 adategységét a sajátjába. Ez az fejléc a feltétele annak, hogy létrejöhessen a csomag útja során az L3-L3 virtuális kommunikáció: pl. a küldő tudatja az út során érintett összes -vel, hogy kinek küldi a csomagot vagy az ICMP értesíthesse a küldőt egy esetleges hibáról. Az fejléc: VERS (4 bit) HLEN (4 bit) ToSVC (8 bit) Teljes hossz (16 bit) ID (16 bit) 0 (1 bit) DF (1 bit) MF (1 bit) Frag Offset (13 bit) TTL (8 bit) Protocol (8 bit) Header Checksum (16 bit) Source Address (32 bit) Destination Address (32 bit) Option (0 vagy n*32 bit) ADATOK (n* 8 bit) 5 Ettől még nem a kapcsoló (switch) nevű eszközről van szó, mert az L2-es, azaz MAC címek alapján dolgozik Szarka T.

4 Az csomag tartalmát (16 bit=egy sor a táblázatban) balról jobbra haladva juttatjuk az adatcsatornába. Tehát először a legnagyobb helyiértékű bit (most significant bit, MSB), kerül a vonalra. Figyelmet érdemel a több bájtos egészek kezelése is, mert először a nagyobb helyiértékű bájt kerül a vonalra. Ez a PC használóknak jelenthet problémát, mert az Intel processzorok számábrázolási mechanizmusával ellentétes. Legyünk körültekintőek ebben a kérdésben akkor is, ha egy API-n keresztül kerülünk kapcsolatba az csomag mezőivel, akár mi magunk állítunk össze egy nyers (raw) csomagot. Az előbbi problémakör egyébként a hálózati és végponti bájtsorrend eltéréséből adódik (Network-byte-order ill. Host-byte-order). VERS: Az melyik verziójához tartozik a datagram. Jelenleg ez (0100) az v4 esetén. Kísérleti szakaszban van az ún. v6 rendszer (0110) amely 32 bites címek helyett 128 biteseket használ és még sok új szolgáltatása is van. HLEN: Az fej hossza 32 bites szavakban megadva. Minimális értéke 5, mert a fej első 5 szava mindig kötelező. Maximális értéke 15, mert a HLEN 4 bitjén max.15 ábrázolható. (Tehát az fej max. 60 bájtos lehet. Lásd még az OPTION mezőt.) A HLEN segítségével meghatározható az adatok kezdete az datagramban. A HLEN értéke tipikusan 5. (A gyakorlatban tehát a VERS és HLEN alkotta bájt 45H értékkel rendelkezik.) ToSCV: Type of Service. Részletezve a bitjeit: Precedence Delay Throughput Reliability Cost MBZ Az Internet megjelenésekor a routerek fő feladata az volt, hogy a küldő és a cél állomás között a datagramok útvonalát kijelöljék. Eredetileg az útvonal kiválasztásában lenne szerepe a ToSVC mezőnek, de a routerek manapság már nem így értelmezik ezeket a biteket. Helyette a szolgáltatás minőség biztosításában (Qos) van szerepe a biteknek, pl. a valós idejű Vo forgalom kezelésében. A routereken beállítható a bitek figyelése és értelmezési módja. (Pl. a CISCO routereken vagy a Linux kernel router szolgáltatásában is beállítható a ToS(VC) mező figyelése. Lásd még a DSCP fogalmát.) Precedence: az adott datagram precedenciája (prioritása) három biten. (Lokálisan van jelentősége.) A prioritások növekvő értékük szerint: 0 : Routine 4 : Flash override 1 : Priority 5 : CRITIC/ECP 2 : Immediate 6 : Internetwork Control 3 : Flash 7 : Network Control Például egy ICMP Echo csomag Routine, míg egy ICMP Time Exceeded csomag Internetwork Control prioritással rendelkezik Delay = 1 esetén a datagram alacsony késleltetést igényel. Throughput = 1 esetén nagy átbocsájtóképességű vonalat kér a datagram. Reliability = 1 esetén a datagramhoz nagy megbízhatóságú átviteli utat rendeljen a router. Cost = 1 alacsony költségű átviteli utat rendeljen a datagramhoz a router. Security = 1,1,1,1 (az előző négy bit magas) Az egyes felsőbb protokollok különböző szolgáltatást kérnek, pl.: TCP (control) =1,0,0,0, de a TCP (data) =0,1,0,0 MBZ = ellenőrző bit. Újabb rendszerekben az alsó két biten (Cost, MBZ) egy ún. ECN (torlódásjelző) szolgáltatást realizálnak, ha az átvitelben érintett rendszerek ezt támogatják. Régebbi rendszerek ezt a két bitet 0-0 értékre állították. Egy olyan adó amelyik támogatja az ECN rendszert, 0-1 vagy 1-0 értékű bitekkel küldi el a csomagot. Ha egy ilyen csomag továbbítása közben valamelyik router torlódást érzékel egy útvonalon, akkor 1-1 értéket állít be. Ennek hatására a vevő kéri az adót az adás ritkítására. Teljes hossz: az datagram hosszát adja meg bájtokban. A hosszba az fejléc is beleértendő. Minimális értéke 21 bájt (20 fejrész + 1 bájt adat), maximális értéke TTL (Time to Live): az datagram élettartamának korlátozására szolgál. Minden datagram egy kezdő TTL értékkel rendelkezik. Amikor a datagram áthalad egy routeren (hop), akkor a TTL mező értékét csökkenti a router programja. (Régebben másodpercenként kellett csökkenteni.) Amikor egy datagram TTL értéke 0-ra csökken, akkor a router eldobja a datagramot és egy ICMP üzenettel értesíti erről az datagram feladóját (az adó címe Szarka T.

5 alapján). Ezzel a módszerrel elkerülhető, hogy valamilyen hiba miatt örökké keringjen egyegy datagram az Interneten. (LAN-on belül elég lehet, pl. TTL=5, de az Interneten TTL=100 is javasolható kezdőértékként.) Protocol: Az program demultiplexer funkcióját támogatja ez a mező. Általában azt az L4 (transzport) rétegben implementált protokollt azonosítja, amelyik az adott datagram gazdája. Az előző oldalakról már néhány ilyen protokollt ismerünk, pl.: TCP=6, UDP=17. Néhány egyéb regisztrált protokoll az RFC 1700 alapján: Protokoll neve Protokoll ID (decimálisan) Internet Control Message Protocol (ICMP) 1 Transmission Control Protocol (TCP) 6 Interior Gateway Routing Protocol (IGRP) 9 User Datagram Protocol (UDP) 17 Reservation Protocol (RSVP) QoS 46 General Routing Encapsulation (PPTP data over GRE) 47 Encapsulation Security Payload (ESP) Sec 50 Authentication Header (AH) Sec 51 Enhanced Inter-Gateway Routing Protocol (EIGRP) 88 Open Shortest Path First (OSPF) 89 További részletek: Internet Assigned Numbers Authority (IANA). Source Address és Destination Address: Az adó és a cél címe 4-4 bájton (Lásd az címek szerkezete fejezetben!) Általában igaz, hogy bárhol is jár egy datagram, az adó és a cél címe sohasem változik meg benne! Minden, az Internetre kapcsolódó hostnak legalább egy címe kell, hogy legyen. (Pontosabban a hostok hálózati interfészének, azaz a NIC-nek van címe. Ha egy hostnak több interfésze is van (pl. egy routernek), akkor valószínűleg több címe van. Később bemutatjuk, hogy a célcím hálózati prefixén alapszik a routing, amely az egyik fő szolgáltatása. A következő képernyő képen egy lehallgatott Ethernet keretet látunk. Látszik, hogy a keretben egy csomag található (type=800h). Az pedig egy ICMP üzenetet szállít, mint adatot. Az adatokkal most nem foglalkozunk, csak az fejléc tartalmát vizsgáljuk: Szarka T.

6 Header Checksum: Fejléc ellenőrző összeg. Az ezzel ellenőrzi a vétel helyén, hogy az fejléc (!) épségben megérkezett-e? Egy router a TTL mező megváltoztatása miatt mindig újragenerálja az ellenőrző összeget. Az adatokat majd a transzport protokoll ellenőrzi, lásd TCP és UDP ellenőrző összegek. Az réteg csak az fejléc tartalmával kerül kapcsolatba, ezért nem illetékes az datagram adatait illetően. A Header Checksum generálása úgy történik, hogy a fejléc 16 bites szavait 32 biten összegzik. Az összeg felső szavát hozzáadják az alsó szóhoz, majd az eredmény alsó szavával dolgoznak tovább úgy, hogy az 1-es komplemensét állítják elő. Az adóban, összeadáskor a Header Checksum=0 értékkel vesz részt. Beérkezett csomag fejlécének ellenőrzésekor 0 lesz az ellenőrző összeg hibátlan átvitel esetén. (RFC 1071) Fregmentálás (csomag tördelés), mint az egyik szolgáltatása Az különböző MAC protokollt használó hálózatok fölött működik. Ezek a protokollok eltérő méretű csomagok szállítására képesek, tehát az MTU (Maximum Transfer Unit) jellemzőjük különböző. Az RFC 1191 alapján: MAC protokoll MTU [byte] Token Ring FDDI 4352 Ethernet II 1500 Ethernet ARPANET 1006 X ARCNET 508 Szabványos minimum 68 Pl. olyan routerek feladata lehet az csomagok tördelése, amelyek egy nagyobb MTU-val rendelkező hálózatból, egy kisebb MTU-val rendelkező hálózatba továbbítanak csomagot: A példában R1 fregmentál, az R2 router feladata pedig az, hogy az X.25-ETHERNET II közeghatáron újra összerakja az eredeti csomagot. (Legalábbis ha az csomag címzettje a C hoszt. Amennyiben a B hoszt lenne a címzett, akkor az ő rutinja végezné az összerakást. A tördelés előre megelőzhető lenne, ha a forrás host eleve a csomag által bejárt útvonalon a legkisebb MTU értékhez (Path MTU) igazodna, azaz az csomag méretét 576 bájtosra állítaná. Az Interneten nincs egységesített eljárás arra, hogy hogyan határozhatja meg a router egy útvonal MTU-ját. (Ha tehetjük, próbáljuk ki az EasyMTU.exe programot.) Az egyik lehetséges módszer az, hogy az fejlécben a DF=1 beállítást használ az adó. Amennyiben olyan médiahatárra érkezik a csomag, ahol darabolni kellene, akkor az adott router egy Destination Unreachable (Cél elérhetetlen) üzenetet küld a forrásnak. Ebben az ICMP üzenetben azt jelzi, hogy a csomagot tördelni kellene, de a DF=1! Újabban az ICMP üzenet a közegen használható MTU értékét is tartalmazza. A tördelésre az alábbi megoldások közül valamelyiket használja a router: Minden tördelt darab MTU méretű, kivéve az utolsót. Minden darab azonos méretű. Az első darab MTU méretű, a többi azonos méretű, Az utolsó darab kivételével mindegyik 576 bájtos Szarka T.

7 Nemcsak routernél fordul elő a fregmentálás, mert előidézéséhez elég, pl. egy PING-et használnunk. (Pl. PING x.y.v.x L 3210) Etherneten már (többször) három csomagot okoz. A ping programot később ismertetjük.) Bármelyik gépen az egy API hívással a registry-ből megtudhatja, hogy egy adott interface milyen MTU-val rendelkezik. A tördelés végrehajtása a fenti példában: Figyeljük meg, hogy az eredeti csomag az MTU-t teljesen kihasználja! (20 bájt fej bájt adat.) DF=0 MF=0 FO=0 adat=1480 bájt 1. töredék csomag: DF=0 MF=1 FO=0 adat=552 bájt 2. töredék csomag: DF=0 MF=1 FO=69 adat=552 bájt 3. töredék csomag: DF=0 MF=0 FO=138 adat=376 bájt A példában csak az fej azon mezőit tüntettük fel, amelyek a fragmentálásban szerepet játszanak. DF (Don t Fragment) ne tördeld! A DF bit arra kéri a routert, hogy olyan útvonalat válasszon a datagram számára, amelyen nem tördelik fel a datagramot. (Lehet, hogy ez egy olyan útvonalat igényel, amelyik valamilyen más szempontból nem optimális: drága, lassú, stb.) Az MF (More Fragments)=1 azt jelzi, hogy egy tördelt csomag közbülső darabjáról van szó. Az utolsó darabot MF=0 jelzi. Az FO (Fragment Offset) azt mutatja, hogy az adott töredék által szállított adat az eredeti csomagban milyen offszetten található. A Fragment Offset mező a tényleges offszet 8- ad részét tartalmazza, tehát az adatmező hosszának 8-al oszthatónak kell lennie. (Kivéve az utolsó töredékben.) Az ID (Identification) mező értékét a forrás állítja be. Minden elküldött csomagban az ID előző értékéhez képest inkrementált értékét helyezi el. A tördelést végző router minden töredékbe az eredeti csomag ID értékét másolja be. Ennek a mezőnek a tartalmával azonosíthatók az eredetileg egy csomaghoz tartozó töredékek. Egy beérkezett csomag (csomagok) eldobásra kerülnek, ha: tördelésre lenne szükség, de DF=1: fejrész ellenőrző összege hibás A tördelt csomag töredékei közül valamelyik a várakozási időn belül nem érkezik meg Fregmentálási összefoglalás: az ID, FO, DF, MF mezők együttesen támogatják az datagramok darabokra tördelését, majd összeszerelését. A datagram darabka önálló fejlécet kap és úgy kerül továbbításra. Az Interneten minden hálózatnak el kell fogadnia az 576 bájtos vagy kisebb datagramot. Gyakorlatilag, pl. egy 556 bájtos TCP szegmenst 20 bájtos fejléccel ellátva kihasználható az, 576 bájtos hálózati minimumának datagram maximuma. A Windows operációs rendszerek TCP/ alrendszerének behangolása a registry módosításával lehetséges, erre általában segédprogramokat használhatunk. Windows alatt ilyen, pl. az EASYMTU, amellyel lehetséges az alapbeállításként generált 1500 bájtos csomagok helyett 576 bájtos csomagok beállítása, megelőzve ezzel a kapcsolatot lassító csomagtördelést. Ezen kívül a TCP finomhangolására is képes, de ezt majd később részletezzük Szarka T.

8 Option Előfordulnak olyan feladatok az működése során, amelyek nem oldhatók meg a fejrész kötelező tartalmával. Az alábbi bővítések viszonylag ritkán fordulnak elő, ezért nem állandó mezői az fejrésznek azért, hogy a hálózati sávszélességet ne foglalják feleslegesen. Az kiegészítő szolgáltatásai, az fejrész OPTION mező tartalmán alapulnak. Ez a mező 0 vagy 32 bit többszöröse, de maximum 10*32 bit. (Az fejléc mérete maximum 15*4 bájt lehet.). Az implementációnak képesnek kell lennie az OPTION mező feldolgozására, de a beállítási képesség nem kötelező. Az opciók elhelyezése az OPTION mezőben: fejrész kötelező mezőit követik: Opció 1 EOL Padding (kiegészítés) 32 bitre Amikor több opció szükséges: fejrész kötelező mezői Opció1 Opció 2 Opció 3 EOL Padding Az opció listát az egy különleges opció az EOL (End of Options List) zárja. Az opciók általános felépítése: Opció típusa (8 bit) Opció hossza (0 vagy 8 bit) Opció adat (0 vagy n*8 bit) Az Opció típusa mező felépítése: CF (1 bit) OC (2 bit) Type (5 bit) CF=1 (Copied Flag): a csomag darabolásakor minden töredék fejrészébe be kell-e helyezni az adott opciót. OC (Option Class): - 00 Vezérlési célú opció osztály - 10 hibakeresési és mérési célú osztály - a többi érték fenntartott Type: Az opció tényleges típusszáma. Nem részletezzük, de lásd az Opció típusa mezőnél. Opció típusa mező értékei. (A gyakrabban használatos opciók.) 0: End of Option List (Egybájtos opció, mely az opciólista végét jelzi) 1: No Operation (Egybájtos opció, amely(ek) töltelékként szerepel(nek), hogy az igazi opciók szóhatárra legyenek igazítva a gyorsabb feldolgozás érdekében) 7: Record Route 68: Internet Timestamp 130: Security (Az információ titkosságát jelzi, nem használatos) 131: Loose Source & Record Route 136: Stream Identifier 137: Strict Source & Record Route Az opció hossza mező az adott opció teljes hosszát tartalmazza bájtban megadva, ha létezik egyáltalán ez a mező. Az opció adat mező az egyes opcióknál kerül ismertetésre. Padding: célszerűen 0 tartalmú bájtok, amelyek az fejrész opció mezőjét n*32 bitesre egészítik ki Szarka T.

9 Néhány opció részletesen: Record Route opció: (Type=7) Type=7 Hossz=23 Pointer Címlista Ahol a címlista: cím 1 cím 2 üres üres A Type=7 előtt valószínűleg egy Type=1 van. A pointer kezdőértéke ilyenkor 4, hogy az első cím helyére mutasson. Az opcióval rögzíthető azoknak az útválasztóknak az címe, amelyeken az csomag áthalad. Ezt az információt majd a csomag céljában értékelik ki. A csomag forrása kibocsát egy csomagot, amelyben helyet biztosít az érintett útválasztók címének. A példában 5 útválasztónak van lehetősége arra, hogy saját címét beírja a listába. A pointer mindig egy üres mezőre mutat. A Hossz mezőben egy konstans van, amelyből látszik, hogy hány cím beírására van lehetőség. A Hossz mező tartalma most 23, de általában 3 + 4*N, ahol az N a rögzítendő címek darabszáma. Az előbbi opciót tartalmazó csomag: fej kötelező része Opció adat EOL Internet Timestamp (Type=68) Az egyes útválasztókon való áthaladás időpontjai rögzíthetők a csomagban. Egy-egy időbélyeg 32 bites, amely az éjfél óta eltelt időt mutatja ezredmásodpercekben: Type=68 Length Pointer Owerf. Flag cím 1 Áthaladás 1 cím n Áthaladás n Az opció működése a Flag mező tartalmával finomítható: - Az időbélyeg mellett az címet is rögzítik az útválasztók - A forrás feltölti címekkel az adatmezőt. Majd az így megadott című útválasztók rögzítik az áthaladás időpontját - Csak az áthaladás időbélyegét rögzítik Szarka T.

10 Loose Source & Record Route (LSRR) (Type=131) A forrás által megadott című útválasztókon haladjon a csomag. (Pl. bizalmas anyagok továbbításához, vagy hálózati hibák felderítésére.) Type = 131 Length=3+n*4 Pointer=4 (kezdőérték) javaslat: Type=1 Route List Route List: cím 1 cím 2 cím n Az A forrás csomagot küld a B cél hosztnak az útvonalon. Az A ból küldött csomag célcíme kezdetben R1 6. A Source Route List pedig az R2, R3, R4, B címekből áll. Az R1 hez érkező csomagban az R1 megvizsgálja, hogy a pointer melyik listaelemre mutat, ez most az 1. elem. A csomag célcímét kicseréli az 1. elemben megadott címre, majd saját címét írja be az 1. elem helyére. Ezután a pointert a következő elemre állítja. Minden érintett útválasztó hasonló módon jár el, így a lista a célpontba érkezéskor az érintett útválasztókat tartalmazza. A lista módosulása a csomag útja során: Szakasz Célcím Lista 1 R1 R2 R3 R4 B 2 R2 R1 R3 R4 B 3 R3 R1 R2 R4 B 4 R4 R1 R2 R3 B 5 B R1 R2 R3 R4 (Az adott szakasz célcíméhez érkező csomagban a pointer az aláhúzott lista elemre mutat.) Az előbbi Loose (laza) módszer megengedi a listában nem szereplő útválasztók használatát is. Pl. a 4-es útvonal hibája esetén az R3 ezt tudva R5 felé irányítja a csomagot, amely majd az R4 címét érzékelve az R4 nek továbbítja azt. Strict Source & Record Route (SSRR) (type=137) Ennél a szigorú forrás általi irányításnál a folyamat hibajelzéssel (ICMP: Destination unreachable) megáll, ha a pointer által mutatott cím nem közvetlen szomszédja az aktuális útválasztónak. Az előbbi 4-es útvonal hibáját nem tudja vagy akarja kiküszöbölni a protokoll. Az LSRR ill. SSRR egyaránt 9 címet tud kezelni, ez korlátozza a használhatóságukat. 6 Ez csak a forrás általi útválasztásra jellemző, mert általában a B célcímet a routerek nem módosítják Szarka T.

11 Az címek szerkezete Az a különböző hálózatokban található gépek közötti kapcsolatot hivatott biztosítani. A kapcsolatban érintett gépek között útválasztás segítségével találja meg a datagramok számára az útvonalat. Az címek hierarchikus felépítésű belső szerkezete segíti ennek a feladatnak az ellátását. Minden, az Internetre kapcsolódó gépnek van egy azonosítója, az címe. A nyilvános címek kiosztását egy Internetet felügyelő szervezet az InterNIC 7 ( ellenőrzi és végzi. Az InterNIC az címeket szervezeteknek osztja ki. Egy-egy szervezet az általa üzemeltetett gépek számának megfelelő (osztályú) címet kap hálózata (!) részére. Az címek 4 bájtosak, azaz 32 bitesek. Írásmódjuk olyan, hogy a négy darab 8 bites címkomponensének decimális értékét írjuk le. Ez az ún. Dotted Decimal Notation (DDN) alak, pl Az Ip címek két fő részből állnak: A cím hálózati része (prefix, előtag) azonosítja azt, hogy az Internetet alkotó hálózatok közül a címmel jelölt végpont mely hálózatban van. A cím végpont azonosító része pedig azt mutatja, hogy az Internet előbbi hálózatán belül melyik számítógépről van szó. Az címek osztályuktól függetlenül 4 bájtosak és az első bájtjuk mutatja, hogy az A-E osztályok közül melyikbe tartoznak (Network ID=x, Host ID=y): Class 1. bájt 2. bájt 3. bájt 4. bájt Hálózat cím Hálózat db Host db Host cím (végpont azonosító) Címtartomány Privát címtartomány A 0xxxxxxx yyyyyyyy yyyyyyyy yyyyyyyy B 10xxxxxx xxxxxxxx yyyyyyyy yyyyyyyy C 110xxxxx xxxxxxxx xxxxxxxx yyyyyyyy D 1110aaa aaaaaaaa aaaaaaaa aaaaaaaa - - E y.y.y- 126.y.y.y y.y y.y y y Az cím két komponense eredményezi, hogy az címek hierarchikusak. Ez a hierarchikus belső szerkezet biztosítja azt, hogy az irányítható protokoll, ellentétben pl. a ma már alig használt NetBEUI protokollal. Az irányíthatóságot az teremti meg, hogy a routereknek nem kell az összes címmel rendelkező eszköz helyét ismerniük az Interneten, elég a hálózatok (egy részének) ismerete. Egy hálózat irányának (helyének) ismerete a benne lévő végpontok helyének ismeretét is jelenti. (Pl. egy A osztályú hálózat helyének (irányának) ismerete elméletileg darab címmel rendelkező eszköz ismeretével ér fel.) Ezzel a módszerrel az egyes útválasztók routing táblájában elhelyezendő útvonalak (hálózatok) száma kezelhető méretűvé válik. Az egyes hálózatokban található gépek nyilvántartása már az egyes hálózatok belső feladata. Tehát a hálózati cím a gépek egy csoportjának címzésére használható és egy csomag útja során mindig a cél hálózatcíme alapján történik az útválasztás. A osztályú cím egy 8 bites prefixet (hálózatcímet) (x) és 24 bites host címet (y) tartalmaz. Ebből az következik, hogy az Interneten 126 darab A osztályú hálózatot lehet kialakítani és egy-egy ilyen hálózatban max. 16,777,214 darab host helyezhető el. Már a hálózat címeknél 7 NIC= Network Information Centre. (Ebben a környezetben tehát nem a hálózati csatoló kártyát jelenti!) Szarka T.

12 is gyanút foghattunk, mert a 7 bites hálózatcím 2 7 =128 db hálózat kialakítását tenné lehetővé, de hová lett két hálózat? A választ az az általános szabály jelenti, hogy a Network ID-ben nem lehet az összes bit egyszerre 0 vagy 1, mert ezeknek speciális jelentése van: a 0 hálózatcím az aktuális hálózatot jelenti. (Ezzel úgy hivatkozhat valaki az aktuális hálózatra, hogy nem ismeri a számát.) A tiszta 1 hálózatcímet az üzenetszóráshoz használják. A cím Host ID komponensében a tisztán 0 és 1 értékek nem egy host kijelölésére használatosak, hanem a hálózatot azonosítják, illetve az üzenetszóráshoz szükségesek. Összefoglalva az A osztályú hálózatokról szóló tudnivalókat: az Interneten 126 db A osztályú hálózat lehet, egyenként legfeljebb hoszttal. Az A osztálynál az Internet cím első bájtja a [1..126] tartományból kerülhet ki és ez azonosítja az adott hálózatot. A hálózaton belül sok-sok gép lehet, de a legkisebb hoszt cím a hálózaton belül a és a legnagyobb a Az címeket decimálisan írják fel és az egyes bájtokat ponttal választják el egymástól. Példaképpen az A osztályú címtartomány legkisebb és legnagyobb címét használjuk az címek szemléltetésére: és A osztályú hálózati címmel a legnagyobb (világméretű) szervezetek rendelkeznek, pl. U.S Department of Defense. A prefixhossz és az cím együttes megadása A osztályú címnél, pl /7 B osztályú hálózati címek: az Interneten db egyenként gépet (hosztot) tartalmazó B osztályú hálózat alakítható ki. A B osztályú hálózatok címtartománya a cím hálózati komponensét vizsgálva: Binárisan is részletezzük a gyakorlás miatt: (Látszik hogy a tiszta 0 és 1 bitet elkerültük a hálózati címben.) Nagyobb szervezetek, pl. egyetemek kapnak B osztályú címet. Érdekesség, hogy pl. a Microsoft megvásárolta a hálózati címet (pontosabban a teljes címtartományt) az eredeti tulajdonosától. A Windows operációs rendszerek elinduláskor DHCP nélküli hálózatban az előbbi hálózati címtartományból választanak egy címet. Ha az adott címet más nem használja a hálózaton belül, akkor indul az OS TCP/ alrendszere. Az előbbi címtartomány tehát a Windows hálózatok privát címtartományának tekinthető 10. C osztályú hálózati címek: Az Interneten darab C osztályú hálózat alakítható ki egyenként 254 hoszttal. A C osztályú hálózatok címtartománya az cím hálózat komponense alapján: Egy konkrét hálózat gépeinek lehetséges címeit vizsgáljuk meg úgy, hogy a vizsgálathoz a legkisebb hálózatcímű C osztályú hálózatot választjuk ki: magának a hálózatnak a címe, hoszthoz nem használható az 1. hoszt címe lehet a 2. hoszt címe lehet. * az utolsó hoszt címe lehet üzenetszórás a hálózaton belül, nem hoszt cím. D osztályú címeket a többesküldéshez (multicast) használják. Ezek olyan címek, amelyek lehetővé teszik, hogy több gép (hoszt) vegyen egy ilyen címmel rendelkező datagramát. (Pl. videó konferencián többen látják ugyanazt a képet vagy a Norton Ghost egyszerre több gépnek is továbbítja a merevlemez partíciót.) Egyes hálózati szolgáltatások (protokollok), pl. R v1 kezdetben broadcast címzéssel dolgoztak. Továbbfejlesztésükkor (pl. R v2) igyekeztek csökkenteni a nem érintett gépek terhelését ezért áttértek multicast címre. (Tehát a broadcast címzéshez képest bizonyos értelemben fejlettebbnek tekinthető a multicast címzés.) A többesküldéshez biztosított címtartomány: A többesküldéshez használt címeknek nincs belső szerkezete, így 2 28 különböző csoportot lehet kialakítani. 9 Természetesen ezek a gépek nem azonos hálózatban találhatók, mert a hálózati azonosítójuk eltérő. 10 Kis Balázs: Windows 2000-Haladókönyv haladó szoftverhez. Szak kiadó Szarka T.

13 Megkülönböztetik az ideiglenes és az állandó csoportok címeit. A multicast műveletekhez speciális protokollok kellenek, pl. IGMP, PIM, stb., de ugyanez vonatkozik a műszerekre is, pl. PING helyett MCAST használatos. A csoportcím használatát az útválasztó felé is jelenteni kell, sőt speciális irányító protokollok kellenek a multicast című csomagokhoz: MOSPF, PIM, DVMRP. Példa állandó csoportok címeire (Internet Assigned Numbers Authority): Az egy LAN-on lévő összes hoszt. (A gép indulásakor már tagja ennek.) Az egy LAN-on lévő összes router Az egy LAN-on lévő összes OSPF router Az egy LAN-on lévő összes kijelölt OSPF router DHCP szerver és átjátszó Privát célra használható multicast címtartomány. LANon belüli multicast címek. Pl. a (DHCP-hez hasonló) MADCAP szerver osztja ki. Az ideiglenes csoportokat létre kell hozni a használatuk előtt. Az egyes alkalmazások megkérhetik a hosztjukat, hogy lépjen be egy csoportba. Ekkor a csoport jelen lesz a hoszton. Minden hoszt (ill. NIC) nyilvántartja, hogy milyen csoporthoz tartoznak az adott pillanatban az alkalmazásai. A multicast routingot majd az irányító protokolloknál fogjuk megvizsgálni. E osztályú címtartományt jövőbeni felhasználásra tartják fenn: Speciális jelentősége van a 127.X.X.X jellegű címeknek. Az ilyen címekre küldött datagramok nem kerülnek ki a hálózatra, úgy érkeznek vissza a küldő protokollhoz. Ezt a visszacsatolást tesztelésre lehet felhasználni. Egy virtuális interfészt is bevezettek a visszacsatoláshoz jelzésére, az ún. loopback interfészt, amelynek címe, pl (Ez egy virtuális interfész, ellentétben a hosztban fizikailag is megtalálható, pl. ETHERNET kártyával.) A lényeg tehát az, hogy segítségével hálózat nélkül is ki tudjuk próbálni a TCP-t vagy UDP-t használó, végeredményben alapú programjainkat és a protokoll vermet. Ha egy processz csomagot küld erre a címre, akkor visszakapja a csomagot. Összefoglaljuk a speciális jelentésű címeket: Netw. ID: Host ID: Magyarázat: cím Egy hoszt címzése a hálózaton belül, a hálózat címkomponensének használata nélkül. cím Adatszórás (broadcast) távoli hálózaton. (Minden gép veszi a célhálózaton belül.) Adatszórás helyi hálózaton belül. A routerek nem továbbítják. Megtévesztő módon gyakran fizikai broadcast címnek nevezik. Pl. olyan rendszer használja induláskor, amelyik nem ismeri a saját hálózatcímét. cím Egy hálózat címe. (Régi rendszerekben ez volt a broadcast.) Az alapértelmezett router jele a routing táblában. 2. Ezzel indul egy hoszt, amelyik később kap címet a hálózatról. Csak forráscím lehet, pl. egy DHCP kérésben. 3. Régi rendszerekben ez volt a broadcast cím. 127.X.X.X Loopback cím. A számítógépen belüli hálózati funkciók hálózat nélküli teszteléshez. Privát (lokális) címtartományok: Tegyük fel, hogy van egy olyan hálózat a cégünknél, ahol alapú szolgáltatásokat használunk (Intranet). Milyen címeket rendeljünk az egyes gépekhez? Amíg nem kapcsolódunk az Internetre, addig elméletileg bármilyen címet 11 Pl. egy W98 az indulásakor rengeteg csomagot is generál. Ezek közül néhány olyan ICMP Router Solicitation csomag, amelynek célcíme Szarka T.

14 használhatunk, lényeg a LAN-on belüli egyediség. Probléma akkor jelentkezhet, ha a hálózatunk az Internethez kapcsolódik (akár csak ideiglenesen is), mert lehet, hogy van olyan belső címünk, amit odakint az Interneten jogosan használnak, viszont a miénk nem az InterNIC-től kapott legitim szám. A megoldás az, hogy olyan címtartományból kell címeket választani az Intranetünk hosztjai számára, amelyeket az Interneten nem osztanak ki, mert a szabvány szerint fenntartják a LAN-ok belső használatára: A osztály: ( /8) B osztály: ( /16) C osztály: ( /16) Ezeket az a címeket az Internet routerei nem engedik át, tehát az ilyen címeket használó LAN-ok egymást nem fogják megtalálni az Interneten. Viszont az előbbi LAN-okat az Internettel összekapcsoló routerek legális, Interneten használatos címmel rendelkezhetnek és képesek ezen legális cím felhasználásával, a belső privát címekkel bíró hosztok számára Internet elérést biztosítani. Pl. egy cím mögött sok gép lehet, lásd később a címfordítást. Az ábrán két olyan LAN látható, amelyen belül a privát tartományból választott a rendszergazda címeket. Az R_x-el jelölt gépek két-két hálózati interfésszel rendelkező 12 routerek: egy-egy ETHERNET interfész a LAN-hoz kapcsolja a gépeket, míg egy-egy modem a telefonvonal segítségével az Internet szolgáltatóhoz 13 (ISP, Internet Service Provider) kapcsolja az R_x jelű gépeket. Az ISP a saját Interneten élő címtartományából ad egyet-egyet a bejelentkezett ügyfeleinek (pontosabban itt az R_x jelű gépek M jelű modemjei kapnak Interneten élő címet.) Ezzel az címmel a modemes kapcsolat időtartamára az Internet részévé válnak a R_x jelű gépek. A példa alapján számos fogalom bevezetésére van lehetőség, melyek magyarázatára a későbbiekben sor kerül. Az R_x jelű gépek különböző hálózatokat kapcsolnak össze (a LAN és az Internet), mert a két interfészük más-más hálózathoz kapcsolódik. Ezeket a hálózatokat a hálózatcímük alapján egy router képes megkülönböztetni. A router funkció kevés ahhoz, hogy a LAN gépei tudjanak kommunikálni az Interneten élő gépekkel, mert mint arra emlékszünk, olyan címtartományból kaptak címeket, amelyek az Interneten nem élnek és ráadásul a routerek sem továbbítják a privát címtartományba eső címekkel rendelkező csomagokat. A LAN-ok R_x jelű gépe az, amelyik legális címmel is rendelkezik (a modemes kapcsolat alatt), ezért képes kommunikálni az Internet gépeivel. Az R_x jelű gép a LAN-on belül a privát címet kapott ETHERNET interfész segítségével kommunikálhat.a routeren egy spe ciális (címfordító) programot kell futtatni ahhoz, hogy a LAN gépei is teljes értékű Internet eléréssel rendelkezzenek (amíg tart a modemes a kapcsolat az ISP gépével). A futtatandó program a NAT-ok (Network Address Translator) családjába tartozik amelyet később részletezünk. 12 Ezek a gépek több hálózatnak a részei, ezért multihomed gépeknek is nevezik őket. 13 Pl. T-COM, UPC Szarka T.

15 Routerek (útválasztók) A példánkban feltételeztük, hogy a cégünk publikus Internet címmel szeretné a LAN I. minden gépét ellátni, ezért C osztályú címtartományt igényelt az InterNIC-től. Az InterNIC válaszában az utolsó C osztályú címet regisztrálta 14 cégünk részére: Az utolsó bájt 0 értéke utalás arra, hogy valójában egy hálózat címét kaptuk, amelynek címtartományán belül szabadon oszthatjuk ki az címeket. (Az ábrán látható konkurens cég B osztályú hálózatot alakított ki....) Emlékeztetőül a hálózatunkban található gépek címe a következő tartományból kerülhet ki , tehát 254 darab gépnek tudnánk közvetlenül címet adni. Miután megvan az címtartományunk, jelöljük ki az egyes gépek (interfészek) címét, de a fizikai (MAC) címük feljegyzése is hasznos lehet: Host Interfész cím MAC cím R_A Ppp R_A Eth A-29-C4 H1 Eth H2 Eth H3 Eth C2 Az -ről tudjuk, hogy feladata a datagramok célba juttatása. Ehhez a datagramok útját ki kell jelölni. Ez a folyamat az útválasztás (routing). Az algoritmust a hálózati rétegben implementált program (rutin) realizálja, amelynek az adatbázisát (routing tábla, forwarding table, csomagtovábbítási tábla) nekünk kell beállítanunk és/vagy a routereken futó irányító protokollok (R, OSPF, stb.) manipulálják. A routing táblát minden gépen egyedileg kell beállítani a hálózat (LAN) sajátosságainak megfelelően. Egy tipikus routing tábla modell a következő mezőkkel rendelkezik: Destination (Network), Gateway, Netmask, Interface. A routolás során az rutin meghatározza a datagram útjának következő állomását és azt, hogy ehhez a datagramnak melyik interfészen át kell távoznia az adott gépről. Ezt követően az ARP felderíti, hogy a MAC rétegnek milyen fizikai címre (!) kell eljuttatnia a MAC keretbe foglalt datagramot. Ezekből két fontos dolog következik: Az a LAN-t és a WAN-t használja (pontosabban azok MAC alrétegét) az datagram továbbítására, ezért kell fizikai (MAC) címre továbbítani a datagramot! Az datagram feladója és címzettje a datagramban mindig ugyanaz marad. (A kivételekkel (NAT és a forrás általi csomagirányító opció) most nem foglalkozunk.) 14 Nyilván a NIC magyar megbízottján keresztül történt a cím kiosztása. A regisztráció biztosítja, hogy senki sem használja ugyanezt a címtartományt, így az egyedül cégünké Szarka T.

16 Hogyan választja ki a router a továbbításhoz használandó útvonalat? (Ezt én az útválasztás első (látványos) részének nevezem.) Következzen két egyenértékű magyarázat: 1. A routoláskor az útválasztó rutinja sorról-sorra halad a routing táblában és az éppen továbbítandó csomag cél címét minden sorban bitenkénti AND kapcsolatba hozza az adott sor Netmask értékével. Az AND kapcsolat eredménye összehasonlításra kerül a sor Destination mezőjében feltüntetett hálózat címmel és amelyik sorban megegyezik a két érték, annak a sornak az interfészén át kell továbbküldeni az datagramot. 2. A routoláskor az útválasztó rutinja sorról-sorra halad a routing táblában azt keresve, hogy melyik sorban található az a hálózat, amelynek címtartományába illeszkedik a címzett címe. A hálózat kezdőcíme a Destination mezőben található, címtartományát pedig a vele egy sorban lévő Netmask-ból lehet meghatározni. Amelyik sorban megvan a keresett címtartomány, annak a sornak az interfészén át kell továbbküldeni az datagramot. Későbbiekben majd előfordul olyan eset, hogy a címzett címe több útvonalbejegyzés címtartományába is beleillik. Ekkor ezek közül a leghosszabb prefixszel (netmaszkkal) rendelkező útvonalon kerül továbbításra a csomag. Ez az ún. classless (osztály nélküli) útválasztás lényege. A mára már elavult classfull útválasztást egy későbbi Az útválasztás alapjai és CISCO IOS parancsok statikus útvonalak beállításához fejezetben ismertetem. Megjegyzések: Pillanatnyilag osztály alapú hálózatcímeket találunk a Destination oszlopban. Ebben az esetben cím első oktettjéből netmaszk nélkül is meghatározható, hogy melyik osztályba tartozik. (Pl. a 223-ból következik a C osztályú netmaszk.) Az osztály alapú hálózatcímeket felváltó rugalmasabb hálózatcímeknél a destination egy szuperhálózatot vagy alhálózatot is jelölhet, itt már nagyobb szerepe lesz a netmaszknak. A routing tábla egy sorát (bejegyzését gyakran útvonalnak) is nevezik. Számunkra azért hasznos az útválasztás algoritmusának ismerete, hogy a routing táblák kitöltésére és ellenőrzésére képesek legyünk. Vizsgáljuk meg, pl. a LAN I.-ből a H3 routing tábláját: Destination Gateway Netmask Interface Eth Lo Eth0 A routing táblában azokat a hálózatokat (Destination) találhatjuk meg, amelyeket a routernek ismernie kell. Hivatalból ismeri azt, amelyikben van működőképes interfésze, de a többit már az irányító protokoll vagy a rendszergazda ismerteti meg vele, azaz veszi fel a routing táblájába. Három féle bejegyzést különböztethetünk meg a routing táblában: 1. Közvetlenül (direkt módon) elérhető egy adott hálózat, ha a hálózat címtartományában van a H3 router valamelyik interfésze. A példában ezt az esetet látjuk az első sorban. 2. Olyan hálózatot is fel kell tüntetnünk, amelyik a felügyeletünk alatt van ugyan, de a H3 nem látja közvetlenül, csak egy (vagy több) routeren keresztül érheti el. Ilyenkor a destination és az interfész értelemszerű kitöltése mellett a gateway mezőbe be kell írni annak a routernak az címét, amelyen keresztül (tehát indirekt módon) elérjük a hálózatot! Az indirekt elérés feltétele, hogy a gateway mezőbe írandó routert az interfészünknek MAC szinten el kell tudnia érnie. Tehát legfeljebb hub, switch segítségével, ha nincsenek közös médián. Megjegyzés: felesleges itt a 2-es kategóriában feltüntetni azokat a hálózatokat, amelyek a 3-as tipusú bejegyzés útvonalán fekszenek. 3. A routing tábla bejegyzések harmadik változata az alapértelmezett útvonal, amely szintén indirekt jellegű, de a további részleteire később térünk vissza Szarka T.

17 A netmask szerepének megértéséhez elevenítsük fel, hogy a destination oszlopban hálózatok címei vannak. A netmask oszlopban azt adjuk meg, hogy a routing tábla segítségével irányítandó csomag célcímének, hány bitjét kell összehasonlítani egy adott sorban az ott található hálózat címmel (a mintaillesztés hány bitre terjed ki). Az 'A' osztályú hálózat esetén 8 bites a hálózatcím, így a netmaszk vagy prefixes alakban /8. A netmask konkrét megadása helyett, annak hosszát tartalmazó táblázatok is vannak, bár ez módszer számítás igényesebb. (Az előbb az AND egyik operandusát készen kapta a gép, míg itt ki kell számítani az operandust). Az előbbi routing tábla ebben a másik alakban: Prefix Next-hop Interface Mode /24 - Eth0 Direct /8 - Lo Direct / Eth0 Indirect A prefix a cím hálózati komponensének bitekben mért hosszát határozza meg (24 bites vagy 8 bites, stb.). A next-hop (következő útválasztó) mező azt mutatja, hogy a célt közvetlenül érjük el, vagy egy router segítségével. Ezt redundáns módon a Mode is leírja. Visszatérve a konkrét routing táblára, először minden H3-hoz közvetlenül csatlakozó 15 hálózathoz kell egy netmaszkot 16 készíteni. Most csak egy hálózat van, a című. (Erre kapcsolódik rá a H3 Eth0 jelű interfésze, ami röviden a H3 egyetlen ETHERNET kártyáját jelöli.) A megoldáshoz még az cím szerkezetét is idézzük fel: Network ID Host ID Itt konkrétan: cím Az első példa egy hálózaton belüli cím. Közvetlen (direkt) példa: útválasztás. A cím Host ID komponensét nullázza a netmaszk, előállítva Netmaszk: ezzel a hálózat címet. A Network ID komponens nem változik. Az ÉS eredménye: A routing tábla destination mezőjében felvettük ezt az értéket. A második példában a konkurens cég hálózatából vizsgálunk egy címet. Nincs olyan interfészünk, amelyik közvetlenül 2. cím kapcsolódna arra a hálózatra, ezért majd csak a tábla gateway példa: sorában, egy netmaszkkal tudunk interfészt rendelni az adott című datagramhoz. (Közvetett (indirekt) útválasztás.) Netmaszk: Az ÉS eredménye: A H3 csak egy hálózatot lát, tehát letudtuk az ilyen szemlélettel elkészített sorokat a routing táblában. A routing táblák több speciális 17 sora közül most még kettőt említünk meg. Az első a loopback (Lo) eszközhöz tartozó sor, amely minden 127.x.x.x című datagramot erre a virtuális eszközre irányít. Segítségével a H3-ra telepített TCP/ rendszer egy része a fizikai hálózat nélkül is ellenőrizhető, pl. a címmel. 15 H1, H2, H3 az általuk ismert hálózat közvetlenül érik el. Közvetett útválasztásról később lesz szó. 16 A netmaszk mindig azé a hálózaté, amelyikre az adott interfész csatlakozik. 17 A broadcast és multicast címzésű datagramokat is kezelnünk kell, pl. az broadcast domain kijelöléséhez Szarka T.

18 A második az alapértelmezett átjárót (default router vagy default gateway) jelöli a következő szemlélet alapján. Az sorról sorra halad a routing táblában és a Destination sehol sem egyezik meg az AND kapcsolat végeredményével. Ez azt jelenti, hogy a H3 nem ismeri azt a hálózatot, amelyikben a cél címe található. Valószínű, hogy az Interneten van a címzett. Küldjük el tehát a LAN-unk routerének az datagramot! Hozzunk 0-val (speciális netmaszkkal) AND kapcsolatba minden bájtot a cél címében, majd a Destination-ba a értéket írjuk be várható eredményként. (Csak egy ilyen ún. default router 18 sor lehet a routing táblában.) Más megközelítésben a gateway (ill. next-hop) mező azt határozza meg, hogy a csomag továbbításához az ARP az csomagban szereplő célcímhez tartozó MAC címet kérdezze-e le, vagy az itt megadott router MAC címét. Indirekt továbbítás esetén elterjedten használják az ún. proxy ARP eljárást. Ekkor a routing táblában nem adják meg a következő útválasztó címét (gateway mező), csak a következő útválasztó felé vezető interfészt jelölik meg 19. Ekkor az interfészen kimenő ARP kérésre az interfészen át elérhető router fog válaszolni saját MAC címével, legalábbis akkor, ha látja azt a hálózatot ahol a cél van és az oda küldött saját ARP kérésével felderítette a cél MAC címét Ezzel az adott gépen (H3) futó rutin befejezte a routolási tevékenységét, mert meghatározta, hogy a LAN-on belül hová kell küldeni az datagramát. Belátható, hogy a H1, H2 gépek routing táblája is megegyezik a most megismert táblázattal, ezért azokat külön nem tárgyaljuk. Az R_A router routing táblája és értelmezése: Destination Gateway Netmask Interface Eth Lo Ppp0 Első sor jelentése ugyanaz, mint H1, H2, H3 esetén: minden olyan host, amelyiknek címe a LAN-unk címtartományába esik, az Eth0 interfészen keresztül érhető el. Második sor jelentése sem változott: a routeren 20 telepített TCP/ rendszer egy része a fizikai hálózat nélkül is ellenőrizhető, pl. a címmel. Harmadik sor: az R_A router nem tudja, hogy a vizsgált címhez tartozó hálózat hol található. (A vizsgált cél cím a destination mezőkben megadott hálózatok közül az egyiknek sem része. Másképpen: egyik hálózat címtartományába sem illik bele.) Ilyenkor egy olyan routerre küldjük a datagramát, amelyik remélhetőleg sokkal több hálózatot ismer. (Pl. az ETHERNET LAN II.-t biztosan ismeri.) R_A router egy modem segítségével kapcsolódik az ISP, Interneten lévő című modeméhez. A routerünk modemének, mint interfésznek 21 a jele Ppp0 a LINUX rendszerben. Az ISP routerének táblázatából egy részlet: Destination Gateway Netmask Interface Megjegyzés Ppp2 A mi cégünk hálózatát hivatalból ismeri a router Ppp3 A konkurens cég hálózatát szintén hivatalból ismeri a router. 18 Figyeljük meg azt, hogy a default router az amelyen át kiléphetünk a hálózatunkból. 19 Ez rugalmasabb mert az cím esetleges megváltozásakor is tovább működik. 20 Nyilván ez minden gépen igaz, de most épp a routert vizsgáljuk. 21 Pontosabban a PPP (protokollt) jelzi, amely mintegy elfedi a modemet Szarka T.

19 Megjegyzések: Ha feltételezzük, hogy a négy modem fix címmel rendelkezik, akkor nincs olyan nagy szükség a DHCP protokollra, bár más paraméterek aktualizálása miatt jól jöhet. Van arra is lehetőség, hogy a routerek külön szerviz protokoll segítségével kommunikáljanak egymással (R, ill. OSPF szerint) a routing táblák aktualizálása érdekében. Összefoglalás: A routolás után kaptunk egy címet és egy interfészt, amelyre, ill. amellyel küldeni kell az datagramát. Tehát a datagram továbbításához megvan a feladó és MAC címe, valamint a cél címe is ismert, mert az fejlécben megadott címre küldjük a datagramát akkor, ha valamelyik interfészünk a cél (al)hálózatára csatlakozik, ill. egy router címére küldjük akkor, ha egyik interfészünk sem látja közvetlenül a célt. Az cím nem elég a datagram továbbításához, mert az interfészek fizikai (MAC) címmel dolgoznak! A fizikai címet az nem ismeri, mert működése logikai címeken alapszik, így most az csomag útjának következő állomásához 22 tartozó logikai cím meghatározásával a tudománya végetért. A datagram következő állomásának címét átadja a TCP/ keretprogramnak, amely az ARP (Address Resolution Protocol) segítségével az állomás címéhez tartozó MAC címet meghatározza. Így már semmi akadálya annak, hogy a keretprogram az LLC protokollnak átadva a datagramot elküldje azt a megadott gépre. Ha a megadott gép címe azonos az datagramában megadott címmel (ez az (al)hálózaton belülre szánt datagramnál következik be), akkor az a beérkezett datagramot átadja a transzport rétegnek további feldolgozásra, majd innét az alkalmazási rétegbe kerülve hasznosul 23. Ha egy routerhez érkezik a datagram, de a datagram fejlécében nem a router címe van, hanem más cím, akkor a router nem adja ki az rétegből az alkalmazási réteg felé, hanem az programmal újra routoltatja a saját routing táblája alapján. (Itt látszik, hogy egy sima W9X még több hálózati interfész esetén sem router, mert nem tudja egyik interfészéről a másikra kapcsolni a beérkező, de nem neki címzett datagramot, ezért eldobja azt.) A hálózati interfészek két fajtáját használja hálózatunk. Az üzenetszórás jellegű ETHERNET interfész esetében fontos szerepe van az ARP használatának, hogy eldőljön az, hogy (sok lehetséges ETHERNET interfész közül) a MAC szinten kivel kell kommunikálni. A két pont közötti kapcsolatot megvalósító PPP interfész esetében a média kizárólag egy-egy interfészt köt össze, így az ARP bizonyos esetekben felesleges lehet. A funkciók szétválasztását érzékelteti, hogy a routing táblákban csak logikai () címek vannak. szinten elvonatkoztatunk attól a fizikai hálózattól, amelyen fut a rendszer. Az ARP táblában (cache) a fizikai címek mellett címek is találhatók (kapcsoló mezők). Második példa: Cégünk felvásárolta a konkurenciát és a két LAN-t össze kell kötnünk. Eddig az Interneten keresztül érhettük el egymás gépeit, de most a megnövekedett LAN-ok közötti forgalom miatt miért fizetnénk többet az ISP-nek? Például a H3-H3 gépek szomszédos irodákban vannak, ráadásul a fiókban találtunk két ETHERNET kártyát a megfelelő hosszúságú UTP kábellel, így már össze is kötöttük a gépeket. Nem lesz hatalmas forgalom a két LAN között ezért sima munkaállomásokat fogunk routerként 24 használni, nem szükséges dedikált router. (Viszont lehet, hogy az R_A dedikált router.) Nézzük hát az és MAC címek változását: 22 Tudjuk, hogy ez az állomás az csomag cél állomása lehet, vagy egy újabb router a cél állomáshoz vezető úton. 23 Ha esetleg nem saját címe van benne, akkor egy sima hoszt eldobja a csomagot. 24 Egy sima hoszt nincs kialakítva routolásra, nekünk kell engedélyeznünk az beállításoknál: Forwarding Enable Szarka T.

20 A saját hálózatunkban egy új kártyához kell cím: Host Interfész cím MAC cím R_A Ppp R_A Eth A-29-C4 H1 Eth H2 Eth H3 Eth C2 H3 Eth C2 A H3 Eth1 interfésze csatlakozik a másik hálózathoz. A volt konkurencia hálózatában szintén kell egy új cím: Host Interfész cím MAC cím R_B Ppp R_B Eth A-29-C4 HB1 Eth HB2 Eth HB3 Eth C2 HB3 Eth C2 A HB3 Eth1 interfésze csatlakozik a másik hálózathoz. H1, H2: Destination Gateway Netmask Interface Eth Eth Lo Eth0 HB1,HB2 Destination Gateway Netmask Interface Eth Eth Lo Eth Szarka T.