Information Technology | Networks » Fóti Marcell - RRAS, Open Shortest Path First, OSPF

NetAcademia-tudástár RRAS: Open Shortest Path First RRAS sorozatunkban utoljára a RIP útválasztási protokollal foglalkoztunk, és megállapítottuk hiányosságait: lassú konvergenciáját, hurokérzékenységét, 15 hopos korlátját – egyszóval butaságát. A RIP ismert gyengeségeit nem a következő verzió kivárásával kell orvosolni, hanem – ha hálózatunk méretével, bonyolultságával a RIP nem tud megbirkózni – áttérhetünk egy sokkal fejlettebb útválasztási protokoll, az OSPF használtára Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Az OSPF legnagyobb újdonsága, hogy – ellentétben a RIP-pal –útválasztóink nem komplett útvonaltáblákat küldenek át a szomszédos routerre, hanem csak egy icipici táblázatot, melyben az általuk ismert hálózati útvonalak adatai szerepelnek: irány, ár, és állapot. Open Shortest Path First Az

[1] címen található RFC tanúsága szerint az OSPF útvonalválasztók valójában útvonal tervezők, amit úgy kell értenünk, hogy minden egyes router önmagában, intelligensen számítja ki egy-egy IP csomag leszállításának optimális útvonalát. A protokoll elnevezésének tükörfordításával: a legrövidebb útvonalat nyitja meg az áthaladó csomagok előtt Az OSPF bonyolult hálózatok lekezelésére is képes. Nemhogy nem borul ki hurkokkal terhelt hálózatokban, hanem ott érzi igazán elemében magát. Vessünk egy pillantást az alábbi ábrára:  Hurkokkal tarkított vállalati hálózat Ilyen hálózatban a RIP valószínűleg pillanatok alatt végezne önmagával, pedig ez a hálózat megbízhatóbb csomagtovábbítást nyújt egyszerűbb társainál, mert ha egy útvonal kiesik, szinte biztosan akad más út, melyen a két, sarokba állított számítógép kommunikálni tud egymással. Ehhez természetesen az kell, hogy vonalszakadás esetén

pillanatok alatt átszámítódjanak a közbenső routerek útvonaltáblái. A bal felső gép szeretné megpingelni a jobb alsót. A hálózat jobb alsó részében a kereszttel jelölt helyen szakadás van Mi egyetlen szempillantással fel tudjuk mérni, hogy a fekete útválasztónak a három lehetséges hálózati útvonal közül csak a vastag vonallal jelzett úton szabad elindítania az alsó gép felé a csomagot: a többi út 3-4 router múlva „eldugul”. Igen ám, de az útválasztók nem felülről szemlélik a hálózatot, hanem abban benne állnak. Madártávlatból könnyű megtalálni az Eiffel toronyhoz vezető utat, de Párizs szűk utcáinak egyikén toporogva a feladat korántsem ilyen egyszerű. Mi kell a célpont megtalálásához? Térkép! A Link State Table Térkép sajnos nincs. Felesleges lenne térképet készíteni olyan városban, ahol egyik pillanatról a másikra új utcák születnek, más utcákat eltorlaszolnak, megváltozik az utca neve, vagy a

végpontja. Ehelyett van egy csapatnyi turistánk, akik a város kereszteződéseiben állva figyelik az általuk látható utakat, és – ha változás áll be – közlik közvetlen szomszédaikkal a hírt: teljes szélességében felbontották a Rákóczi utat, vagy fizetőssé vált a Lánchíd használata. Az egyes útválasztók az általuk kezelt hálózatokról, a vonalak állapotáról, áráról stb. táblázatot vezetnek, melynek neve Link State Table. Ezt a - lokális helyzetképet tükröző – táblázatocskát küldik át szomszédaiknak, akik természetesen továbbítják a távolabbi útválasztóknak is. Idővel mindegyik útválasztóhoz eljut a többiek által közölt állapottáblázat És ekkor kezdődik a valódi munka: a beérkezett jelentések alapján minden egyes router elkészíti saját térképváltozatát, melyben nem fognak szerepelni sem a lehetetlen, sem a drága útvonalak. Az előző ábrán a fekete vonal valójában nem más, mint a fekete

útválasztó által generált térkép. Egy-egy útválasztó csak a saját hatáskörébe tartozó útvonalak használatáról dönt, de a döntést a többiek által beküldött Link State Table alapján teszi! Közelítsük az ábrát egy kicsit jobban a valósághoz! Színes, iMAC-like gépeket vásárolunk, hupikéket, ezüstszürkét és bíbort (bár ez utóbbi szín a lapban használt két festék tetszőleges arányú kevergetésével sem lesz más, mint szürke). A bal felső munkaállomás változatlan marad, színpompás gépeinket viszont a hálózat különböző pontjaira helyezzük. A fekete útválasztót megvizsgálva kiderül, hogy a beérkezett Link State Tablek (LST) alapján mindegyik célpont felé tud térképet rajzolni. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár  Az OSPF útválasztó útvonaltáblája különböző célcímeket tartalmaz Ha

megszakítjuk az egyik vonalat, a távoli útválasztók már küldik is vadonatúj Link State táblájukat, és fekete routerünk hamarosan új térképet készít.  Az OSPF útválasztók gyorsan alkalmazkodnak a megváltozott hálózati felépítéshez OSPF fogalommagyarázat Ennyi „matematika” talán elég is lesz (Dijkstra bácsi forog a sírjában), mivel nem tartom valószínűnek, hogy közülünk bárki is belefogna OSPF implementáció készítésébe. Azonban korántsem vagyunk készen Hátra van még az OSPF környezet ismertetése, valamint az RRAS megfelelő beállítása. • Autonomous System (AS). Az egymással Link State Tablet cserélő OSPF útválasztók egy közös Autonomous System részei, közös autentikációval, közös állapotinformációval rendelkeznek. Egy hálózaton elvileg lehet egynél több AS is, ennek azonban nem sok értelmét látom. • Area. Nagy hálózatokban érdemes lehet bizonyos zárt leágazások útválasztóit csoportokba

foglalni A csoporton belül szabadon áramlik a Link State, kifelé viszont a csoport tagjai egyetlen útválasztónak fognak látszani. Az area nagyon hasonló az Active Directory-féle telephelyekhez: kis zárt világ, mely a külvilággal általunk definiált módon kommunikál. Ha a Microsoft nevezte volna el, ma azt mondanánk rá: site. Az areakat IP cím szerű, 4 tagból álló számokkal azonosítjuk, melyeknek valójában semmi közük semmihez: a rendszergazda hasraütéses módszerrel választhat area azonosítókat. Ha nem definiálunk külön területeket, akkor útválasztóink az alapértelmezett, 0000 azonosítót viselő area tagjai lesznek. Egészen pontosan nem az útválasztók tagjai egy-egy areanak, hanem az általuk kezelt vonalak Ezzel elérhető, hogy ha egy router mondjuk három különböző areaba eső hálózatot kezel, akkor tulajdonképpen mindháromnak része. • Range. Egyetlen area egynél több IP tartományt lefedhet Ezt az areahoz rendelhető IP

alhálózatokkal adhatjuk meg • Stub. Stub, vagy végállomás areanak azokat a területeket nevezzük, melyek útvlasztói zárt közösséget alkotnak, külső útvonalakat nem tanulnak meg. • Boundary router. Az előző ellentéte A Boundary, vagy határútválasztó annyi útinformációt gyűjt, amennyit csak tud: statikus bejegyzéseket, RIP-et, SNMP-től tanul stb. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár • Hello protokoll. OSPF útválasztóink automatikusan keresik meg társaikat Címzésmódját tekintve Multicast, azaz a periodikusan kibocsátott hellózás nem zavarja a hálózat összes gépét. Alapértelmezésben tíz másodpercenként történik. Szintén alapértelmezés, hogy ha egy útválasztó négyszer egymás után nem válaszol a Hellora, akkor hibásnak kell tekinteni. Lássuk ezek után, hogyan kell öszehozni egy OSPF megoldást a Windows 2000

beépített RRAS szolgáltatásával! Először is telepítenünk kell az OSPF protokollt, ami a szokásos módon, az IP Routing alatti General fülön jobbklattyintva, a New Routing Protocol-lal végezhető el:  Az OSPF telepítése Telepítés után azonnal kezelhetjük az areakat, átállíthatjuk útválasztónkat Boundary routernek, és kiválaszthatjuk, hogy a határvidéken túlról milyen útinformációt gyűjtsön be. Ha az alábbi ábrapáron az OSPF protokoll tulajdonságlapjának első fülén beállítjuk, hogy határvidék-útválasztó legyen, a negyedik fülön kiválaszthatjuk, hogy milyen forrásokból tanuljon:  Határvidék routereken megválaszthatjuk, mit emeljenek be a mi hálózatunkra a külvilágból Az útválasztó protokoll mindaddig nem indul be, amíg meg nem mondjuk neki, hogy mely kártyákon Hellózhat. Ezt az OSPFen jobbkattintva tehetjük meg (New Interface) Vegyünk fel tehát egy hálózati kártyát, hogy azon át OSPF routereink

megkezdhessék aktív hellózásukat: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár  Hálózati kártya felvétele az OSPF hatásköre alá. Ezen a kártyán keresztül tanulni, és tanítani fog Hozzá kell rendelnünk egy előre létrehozott areahoz, be kell állítani, hogy mekkora eséllyel legyen ő a fő-fő Hellózó (designated router priority), valamint hogy a tőle kimenő útinformációkon mennyivel növelje meg a metric (cost) értéket. A jelszóra még visszatérünk, a hálózat típusa ethernet esetén nyilván broadcast. Amint ezen a kártyán elindul a Hello, a rutinos rendszergazda nyomban Network Monitort ragad, és megnézi, hogyan is fest az üzenet a hálózaton. Sorokra tördelve és megritkítva nézzünk meg egy Hello csomagot! Hello ACAPULCO 224.005 IP Az ACAPULCO nevű gép küldte ezt a csomagot a 224.005-ös Multicast (OSPF) címre

Ethernetszinten a célcím így fest: ETHERNET: Destination address : 01005E000005 ETHERNET: .1 = Group address ETHERNET: .0 = Universally administered  address Tehát csoportcím, mégpedig a szabványban rögzítettek egyike (universally administered). IP szinten az érdekesebb adatok: IP: Time to Live = 1 (0x1) Látszik, nem arra tervezték, hogy több hopon átmenjen! Ez egy router-router csomag. IP: Protocol = Open Shortest Path First IGP  (0x059) IP-be ágyazva OSPF utazik. (Mi másra számítottunk?) És most jön maga az OSPF rész: OSPF: Message = Hello OSPF: Version = 2 (0x2) OSPF: OSPF Packet Type = Hello OSPF: Packet Length = 52 (0x34) OSPF: Source Router ID = 169.25412646 OSPF: Area ID = 0.000 OSPF: Authentication Type = Simple Password OSPF: Authentication = 0x3837363534333231 Itt álljunk meg eg pillanatra. Vissza tudjuk fejteni a jelszót (authentication)? Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003,

NetAcademia Kft 5 NetAcademia-tudástár OSPF: OSPF: OSPF: OSPF: OSPF: OSPF: OSPF: OSPF: Netmask = 255.2552550 Hello Interval = 10 (0xA) seconds Router Priority = 1 (0x1) Dead Interval = 40 (0x28) seconds Designated Router = 192.168113 Backup Designated Router = 192.168114 Neighbor = 10.101010 Neighbor = 30.303030 A Neighbor mezőkben olvashatjuk, hogy ez az útválasztó milyen egyéb útválasztókat talált ezen hálózati szegmensen. A hexa panelről ennyit érdemes megfigyelni: 12345678 Ez bizony a jelszó. Enyhén clear text Adapterszinten érdemes még megtekinteni a különböző időzítési paramétereket:  Az OSPF időzítésének alapértelmezett értékei. Hello 10 másodpercenként stb Ezekről annyit érdemes tudni, hogy ha bármelyik útválasztón átállítjuk, akkor a többin is után kell húzni! Miután a kártyákat felvettük, már zajlik a Link State Table cserebere. Le is ellenőrizhetjük az RRAS konzollal, vajon látják-e egymást

útválasztóink. Az OSPF protokoll jobbgombos menüjében ugyanis a következő értékesebb lehetőségek rejlenek: • Show Link State Database. Itt megtekinthetjük, mit is tanult útválasztónk a többiektől Vigyázat! Itt nem konkrét útvonalbejegyzéseket látunk, hanem csak egy tájékoztató táblázatot! Ennek minden gépen közösnek kell lennie – de az ez alapján generált útvonaltáblák már egyediek! (Lásd később.)  A Link State Table közös minden, azonos areaba tartozó routeren. Ez a recept Ebből főzik az egyedi útvonaltáblákat • Show Neighbors. Itt tekinthetjük meg, hogy az OSPF Multicast címre kibocsátott intenzív hellózás milyen eredményre vezetett. Találkoztak-e útválasztóink?  ACAPULCO szomszédai Nem tudom, megfigyelték-e, de ezidáig az OSPF telepítése is éppolyan könnyedln zajlott, mint a RIP-é. Egyszerű hálózatban valóban ennyi, de oda a RIP is elég. Ugyanakkor az eddig említett eszközkészlettel (NetMon,

Show Neighbors, Showw Link State Database) felfegyverkezve összetettebb hálózatokon sem kell tartanunk attól, hogy az OSPF kicsúszik az ellenőrzésünk alól. Sőt! Telepítsd, és felejtsd el! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár A kész útvonaltábla Miután gépeink közös nevezőre kerültek a Link State Table kapcsán, akkor jön a munka oroszlánrésze: egyedi, az ő nézőpontjukból optimális útvonaltáblát kell generálniuk. Ebbe a folyamatba se beavatkozni, se bekukkantani nem tudunk, csa a végerendény a mienk. A szokásos route print paranccsal megvizsgálhatjuk, mi született az OSPF áldásos tevékenysége nyomán. Nem valami látványos, de azért megmutatom:  A route print kimenete. Az utolsó, a Metric oszlop alapján gyaníthatjuk, hogy melyek a tanult és dinamikusan generált bejegyzések Gondok? Hogy a problémákról is szó essen: az

ICMP Redirect csomagot arra találták ki, hogy rossz helyen kopogtató munkaállomásoknak a fejébe verje, merre van az arra. Dupla utas (triangle) útválasztásnál a routerek visszaszólnak a munkaállomásnak, hogy legközelebb merre kellene menniük. Ez nagyon jó dolog A Windows 2000 gépek hálásan fogadják az ICMP Redirectet. Az RRAS is Bizonyos hálózatokon nemkívánatos, hogy a routerek is befogadják az ICMP Redirectet: az RRAS is lebeszélhető erről az alábbi registry kulcs megfelelő értékével: HKEY LOCAL MACHINESYSTEMCurrentControlSet  ServicesTcpipParameters Itt az EnableICMPRedirect értékétvalue 0-ra kell állítani. További érdekes jelenség állhat elő olyan switchek használata esetén, amelyek szigorúan veszik a mulitcast protokollt, de van olyan OSPF routerünk is a hálózatban, amelyik nem. (Az RRAS komolyan veszi) Ebben az esetben ugyanis az történik, hogy az RRAS szabványosan kiküld egy Multicast Join üzenetet, amelyre bizonyos

routerek nem válaszolnak. Ettől az RRAS nem sértődik meg, egyes switchek viszont elzárhatják ezeket a butus routereket a rendes, szabványos RRAS elől. Fóti Marcell marcellf@netacademia.net A cikkben szereplő URL-ek: [1] OSPF Version 2 http://www.ietforg/rfc/rfc2328txt Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár RRAS II. - útválasztási alapok Emlékszem, pár évvel ezelőtt az útválasztás nemigen okozott fejtörést az IT szakemberek többségének: a hálózatok összekapcsolása (ha voltak egyáltalán hálózatok!) még nagyvállalatoknál is ritkaságszámba ment, s Internetkapcsolata sem volt senkinek. Nem túlzok: senkinek! De elmúltak már azok a boldog békeidők, amikor hálózat alatt egy másfél méteres koax kábelt, két T dugót és két lezáró ellenállást értettünk, s annak is vége, hogy "majd a Novell két kártyával

elintézi", hisz az IPX protokoll is kihalóban van. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 8 NetAcademia-tudástár Nézzünk szembe a tényekkel: a hálózatok rohamos burjánzása következtében a rendszergazdák folyamatosan foglalkoznak a problémával, s heti gyakorisággal kerülnek döntéshelyzetbe: kell-e új subnet? S ha igen, milyen IP tartományt kapjon? Mi fogja összekötni az új alhálózatot a régivel? Egy router? Milyen gyártmány? Milyen routing protokollt kell ismernie? Mennyibe kerül? Minden döntési helyzetben célszerű legelőször megvizsgálnunk a szerszámosládát, hátha már birtokunkban van az a szerszám, amire éppen szükség van. Az RRAS szerszámosládája igen gazdag Nem mindenki tudja talán, de egy középkategóriás hardver útválasztót meghazudtoló funkciógazdagságú és teljesítményű eszköz van a birtokunkban! Ismerkedjünk meg a

használatával, hátha beválik. A ládafia átkutatása előtt azonban ismerkedjünk meg az IP útválasztás gyönyöreivel és gyötrelmeivel. Az alapprobléma Miért kell egyáltalán törődnünk az útválasztással? Miért nem oldják meg a gépek önállóan ezt a feladatot? Mert a két pont közötti csomagátvitelért felelős IP protokoll nincs felkészítve ilyesmire (!), lehetőségei nagyon is korlátozottak: egyszerűen nem is teszi lehetővé egynél több hálózat használatát! Az eredeti IP specifikáció ugyanis két, egymással szorosan összefüggő korlátozást is tartalmaz egynél több hálózat esetére: 1. szabály: Minden gép csak a saját hálózatára küldhet csomagot 2. szabály: Ha mégis távoli hálózatra kellene küldeni a csomagot, akkor az első szabály lép életbe Tisztára, mint a "férjnek mindig igaza van" feliratok az ajándékbolt falán. Vagy mint egy börtön: minden alhálózat egy-egy külön börtön. 3. szabály: A

rabok kintről csak az őröktől kaphatnak csomagot 4. szabály: Ha mástól jönne a csomag, akkor az első szabály lépne életbe Egymással természetesen szabadon, a fegyőr közvetítése nélkül is kommunikálhatnak: arra való a radiátorcső :-) Az őrök "segítsége", közreműködése nélkül nincs lehetőség külső kapcsolatra. Ugyanez a helyzet az IP-vel Amint külső hálózatra forgalmazunk, rá kell vennünk a fegyőrt, hogy segítsen. Mindenképpen szükségünk van egy segédre, egy postásra, egy útválasztóra. Egyszerű esetben alhálózatonként egyetlenegy "fegyőr" van - ennek címét írjuk be a Default Gateway, vagy magyarul alapértelmezett átjáró helyére.  Mi a hiba a fenti ábrán? (Rossz a DG.) Gyakori hiba, s MCP vizsgákon számtalan ravasz formában visszatérő feladat a Default Gateway helyes beállítása. A fentiek alapján egyértelmű, hogy ha egy számítógépen a beírt Default Gateway nem a saját routerünk

innenső IP címe, hanem mondjuk például a túlsó lábát, vagy ad abszurdum az Elender egyik gépét adjuk meg (mondván, hogy az közelebb van az Internethez, hű de jó gyors lesz a kapcsolat), akkor a gép nem lesz képes külső kapcsolatot építeni. Idegen nem állhat szóba velünk a saját fegyőrünk közvetítése nélkül! Nincs csalási lehetőség: ha nem él, vagy nem ismert a kapu őrzője, nem jöhet létre a kommunikáció a külső és belső felek között. A fegyőrös hasonlat egyetlen ponton sántít: ha hibás címet adunk meg alapértelmezett átjáróként, akkor nem a fegyőr állítja meg a forgalmat - odáig el sem jutunk. Az IP stack helyes átjáró hiányában helyben eldobja a kifelé irányuló csomagokat A szétválasztás egyébként a saját és a címzett IP címéből képzett úgynevezett Network ID-k összehasonlításán alapul: ha a két Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető 

2000-2003, NetAcademia Kft 9 NetAcademia-tudástár NetID azonos, közös alhálón vagyunk. Ha nem - nem A művelet a saját Subnet Mask segítségével történik olymódon, hogy a Maskkal kétfelé vágjuk a címeket, és ha a "bal" fele (Network ID) azonos a rab börtönazonosítójával, akkor irány a radiátor. A következő ábra az előző alapján készült, ahol immár helyes a DG címe, és megpróbáljuk megpingelni a 23.232323 című gépet Az ábra alsó felében látható, ahogyan a gép eldönti, vajon azonos hálón van-e a végállomással  Az útválasztás módszere: az IP címek szétvágása a Subnet Mask segítségével. Itt jegyzem meg, hogy manapság minden Subnet Mask balról csupa egyes, jobbról csupa nulla, például: 255.2551920=11111111111111111100000000000000 Az eredeti szabvány megengedett "fésűs" maszkot is, melyben vegyesen szerepelhettek egyesek és nullák. Ezt egy későbbi RFC felülbírálta, valószínűleg

azért, mert nem embernek való a vegyes maszkkal történő fejben számolás. Minden Windows router? A legelső szabálypár miatt minden fegyencnek el kell tudnia dönteni, hogy kommunikációs partnere belsős, vagy külsős. Ezen döntések meghozatalára minden IP alapú eszköznek szüksége van, azaz mindegyik IP eszköz egy-egy egyszerű útválasztó is egyben. Erről könnyen meg is győződhetünk, ha parancssorban kiadjuk a ROUTE PRINT parancsot Az alábbi ábrán például egy Windows 2000 Professional (!) útvonaltábláját láthatjuk, ennek sorai egy-egy feldolgozandó irányt jelölnek. Későbbi példáim könnyebb értelmezhetősége miatt célszerűnek tartom a táblázat részletesebb elemzését - hamarosan route tábla műtétre is sor kerül! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 10 NetAcademia-tudástár  A Windows 2000 Professional útvonaltáblája A táblázat első

két oszlopában a célhálózatokat olvashatjuk, a szokásos formában: IP címtartomány eleje 199.1881770 Subnet Mask 255.2552550 Ez a két szám egyértelműen meghatároz egy IP tartományt. Könnyedén kiszámítható a vége, a Subnet Mask ugyanis megadja, hogy hány IP cím esik ebbe a tartományba: ahol nulla áll a maszkban, az mind ide tartozik (az a szabadságfokunk), ergo az utolsó IP cím ebben a kupacban a 199.188177255 Újabb dokumentumokban egy másik jelölésmód is előfordul: 199.1881770/24 A törtjel utáni szám megadja, hogy a Subnet Maskban hány egyes (1) bit van, a 24 tehát megegyezik a 255.2552550-val A fenti ábrán látható útvonaltáblában tehát a következő hálózatok szerepelnek: IP 0.000 127.000 172.1600 172.160111 172.16255255 224.000 255.255255255 SM 0.000 255.000 255.25500 255.255255255 255.255255255 224.000 255.255255255 Hálózat Default Gateway SELF Saját alháló Ez a gép Subnet Broadcast Multicast Globális IP Broadcast A

következő két oszlop a küldési MÓDSZER meghatározására való. Alapvetően háromféle módszer létezik: Ha a 3. oszlop a továbbítás egy „idegen” IP cím a saját Célzott. A csomag az hálónkról „idegen” (router) címre (Itt: 172.1601) kézbesítendő saját címünk Üzenetszórás. Az Ethernet (Itt: 172.160111) majd lerendezi. 127.001 Lokális. A csomagot nem KI, hanem BE kell küldeni az oprendszerbe. Az Interface oszlopban a fenti három továbbítási mód kijáratait, hálókártyáit láthatjuk, végül a Metric oszlop egyelőre nem fontos, majd ha jönnek a Routing protokollok, visszatérünk rá.  Mi hova? A kiemelt sor értelmezése ezek szerint: a 172.160111 címre „induló” (valójában érkező) csomagokat a 127001 (SELF) címre kell továbbítani, tehát be a gépbe. De az is kiolvasható, hogy ha a célgép IP címe mondjuk 193193193193, akkor hogyis? Meg kell keresnünk a 193.193193-as subnetet a legelső oszlopban, s ennek sorából

kiderül, hogy hova kézbesítendő. Nos, 193-as sort nem találunk, de ott a 0000, mely minden ismeretlen címre vonatkozik, "mindent visz": a Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 11 NetAcademia-tudástár 193-as címek, mint teljesen ismeretlenek, célzottan a 172.1601-es címre továbbítódnak, ami nem más, mint a DG Ezzel a trükkel megspórolhatóvá vált, hogy a világ összes IP tartományát fel kelljen sorolni a listában: ami nincs bent, azt lenyeli a 0.000 sor A saját hálózatra való csomagok célcíme egészen másképp fest: mintha önmagunknak küldenénk (127.001 <> 172.160111)! A paraméter helyes értelmezése: ezen a címen/kártyán kell kieregetni, de nem kell vele "célozni", az Ethernet majd elintézi a célba juttatást (üzenetszórás, ARP stb.) Fontos még ismerni a 127.001 címet: ezek megint mi vagyunk, ez a speciális IP cím minden

gépen önmagára mutat A sor értelmezése: ami nekünk jött, az nekünk jött. Nem kell továbbküldeni Ha megpingeljük ezt a címet PING 127.001 Network Monitorral megfigyelhető, hogy a csomag ki sem jut a kábelre (nem látszik belőle semmi). Most lássuk, mit kell tennünk az útvonaltáblával a következő esetekben! Két hálózat összekapcsolása Ha mindössze két hálózatot (mondjuk két irodát) szeretnénk összekapcsolni útválasztóval, nem kell törődnünk sem az RRAS útvonaltáblájával, sem a telepítővarázslóval. A lényeg, hogy az RRAS routing engedélyezve legyen Ilyenkor elegendő, ha az RRAS gépbe beteszünk két kártyát, azokon beállítunk két helyes IP címet, a két oldal munkaállomásainak DG-jét pedig egyszerűen az RRAS-ra irányítjuk. Ez azért elegendő, mert bár a munkaállomások „ismeretlen” cím miatt, a 0.000 címre küldik a csomagokat, a középen álló RRAS mindkét hálózatról tud, így minden beérkező csomagot

ügyesen átemel a másik lábára.  Két alhálózat összekapcsolása Még egyszerűbb a hálózat gépeinek felkészítése, ha az RRAS-ra felteszünk egy DHCP Servert, és mindkét kártya IP címtartományára felveszünk egy scope-t (IP cím készletet), ahol a DG mindkét szkópban a megfelelő RRAS lábra mutat. Többkártyás gépen ennél többre nincs is szükség, mert a DHCP Server meg tudja különböztetni egymástól a bejövő kéréseket, és automágikusan a megfelelő tartományból ad címet. Három alhálózat összekapcsolása Három hálózat láncba fűzése esetén azzal kell számolnunk, hogy a lánc végén tanyázó routerek már nem fogják ismerni a kettővel odébb található alhálózatot, mert oda nincs közvetlen hálózati kapcsolatuk. Lássunk példát!  Három alhálózat esetén már lesznek a routerek számára ismeretlen, „távoli” hálózatok is Itt R1 számára a 3. hálózat közvetlenül már nem érhető el, ismeretlen Első

ránézésre úgy tűnik, hogy elkerülhetetlen R1 és R2 felokosítása, útvonaltáblájuk felkészítése a távoli célok eléréséhez, hisz ha az 1. hálózat egyik munkaállomása R1-hez továbbít egy csomagot, melynek végcélja a 3. hálózat, akkor R1 csak néz bután, nem tudja merre van a tovább Egy kis furfanggal azonban elodázhatjuk az útvonaltábla hekkelését. Mit is kell csinálni minden ismeretlen csomaggal? Hozzávágni a DG-hez! Mi tiltja meg, hogy R1-nek is beállítsunk DG-t? A következő ábrán a görbe nyilak a csomagátdobás útvonalát mutatják, ha mindkét routeren felvesszük a MÁSIKAT DG-nek. Fűszerezzük meg az egészet egy kis DHCP-vel is, és igazán könnyen kezelhető hálózathoz jutunk! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 12 NetAcademia-tudástár  Három hálózat, routolás és DHCP A fenti ábrán a DHCP Servernek már három szkópja (IP

címkészlete) van, de csak kettő alhálózat gépei képesek közvetlenül címet kérni tőle. A harmadik hálózaton ilyen esetekben el lehet helyezni egy DHCP Relay Agentet, mely onnan a DHCP címkérési broadcastokat unicasttá alakítva átdobja a routeren túlra, majd a választ ismét broadcasttá alakítva visszajuttatja a kérelmezőhöz. Alapprobléma II. - gép a köztes hálózaton Három alhálózatból álló környezetben már előáll az a probléma, amit az augusztusi NetMon cikkben részletesen elemeztem: a középső, második hálózaton mi legyen a munkaállomások DG beállításával? Ha R1, az is rossz. Ha R2, az is rossz Egyszerre kettő DG nem lehet. Emlékszik még valaki, mi erre a megoldás? ICMP Redirect! Négy hálózat összekapcsolása Ahogy bonyolódik a hálózat, úgy válik egyre nehezebbé pusztán ravaszsággal megúszni az útválasztótábla matatását. Ha már négy hálózat felfűzésére van szükség  Négy alhálózat

összekapcsolása akkor már nem segít a DG-trükk, ugyanis a középen álló R2-nél a „gép a köztes hálózaton” esete forog fenn, és két DG-t kellene beállítani neki, ami nem megy. Nézzük meg, vajon R1 és R3 esetén beválik-e még a DG-csel: R1 ismeri az 1. és a 2 hálózatot Ha minden további ismeretlen csomagot gondolkodás nélkül áthajít R2-nek, akkor jól továbbítja a 3. és 4 hálóra való csomagokat! Ennek tükörképe az R3, mely így szintén jól működik, ha a DG-je „középre”, R2-re mutat. Az R2 tanítása viszont elkerülhetetlen. Ismerkedjünk meg a Route parancs használatával! Új bejegyzés készítése az ROUTE ADD útvonaltáblába ROUTE CHANGE Meglévő bejegyzés módosítása ROUTE DELETE Sor törlése a táblából Így taníthatjuk meg R2-nek, merre van az első hálózat: route add 10.10100 mask 2552552550 17216233 Ahol a 172.16233 cím R1 „innenső” lába Hasonlóképpen tanítható meg neki a negyedik hálózat holléte:

route add 4.440 mask 2552552550 1921681111 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 13 NetAcademia-tudástár ahol 192.1681111 az R3 „innenső” lába Szabadon kísérletezhetnek Kedves Olvasóink a route tábla rongálásával, mert egyfelől mindig rendelkezésre áll a ROUTE DELETE, másfelől minden bajtól megszabadít egy jóízű reboot. Így nyugodtan kipróbálható, mit szól a masina, ha kiadjuk a következő parancsot: ROUTE DELETE 0.000 0 Megszűnik a távoli hálózatok elérhetősége, de a dolog nem halálos, a route add 0.000 mask 0000 1721601 visszateszi a DG címet (Ahol a 172.1601 a Kedves Olvasó alhálózatán lévő router címe)! N darab hálózat összekapcsolása A következő megoldandó probléma N darab alhálózat összekapcsolása. Az eddigiekből könnyen belátható, hogy a végeken található routerek esetén van némi remény DG-trükkre, de csak addig, amíg

azok összesen két hálózat összekötését végzik. Ha elkezdünk pókhálót alkotni, azonnal elillan ennek esélye, s marad a tanítás. Sajnos a routerek és útvonalak számával exponenciálisan növekszik a szükséges ROUTE ADD parancsok száma, és akkor még nem beszéltünk a hálózat önkarbantartásáról. Körülbelül négy hálózatig érdemes kézzel bíbelődni az útvonaltáblákkal, ennél összetettebb hálózatok esetén kézimunkázni őrültség. A megoldást valamilyen útválasztó protokoll használata jelentheti, melyek közös tulajdonsága, hogy az egyes routerek által természetesen ismert hálózatok adatait automatikusan átvezetik a többi routerre is. Természetesen ismert hálózatnak nevezem azokat, melyek közvetlenül a masinába csatlakoznak: nem kell megtanítani egy routert olyan hálózat elérésére, mely közvetlenül csatlakozik hozzá! Két útválasztó protokollról szólunk a következő hónapban: a RIP és az OSPF-ről, sőt,

megemlékezünk a hamis IP címek által okozott útválasztási agyrémekről is. Fóti Marcell marcellf@netacademia.net MCSE, MCT, MCDBA, MZ/X Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 14 NetAcademia-tudástár RRAS III - Útválasztási protokollok Ez a cikk nem azonnal az útválasztási protokollokkal kezdődik, mert meg kell emlékeznünk a szeptemberi számból terjedelmi okokból kimaradt útválasztási hibákkal, melyek szinte minden hálózaton felbukkannak előbb-utóbb. Csak ezek után térünk rá a RIP útválasztási protokollra. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 15 NetAcademia-tudástár Útválasztási anomáliák Három esetet veszünk szemügyre: 1. Forgalmazás belső IP címekről 2. Hamis IP címek használata 3. Körkörös routolás 1. Forgalmazás belső IP címekről Ez az

útválasztási "hiba" többnyire nem szokott galibát okozni, mert akik tudatosan használják a belső IP címeket hálózataikban, nem lepődnek meg azon, hogy ezeket a nagyvilágban, kint az Internet backbone-on nem fogadják el a routerek. Mely címekről valn szó? A 10000/8, a 1721600/16, és a 19216800/16 tartományok címeiről, melyek a ???-es RFC (tech.net 2000 ??) szerint arra vannak fenntartva, hogy saját hálózatunkon szabadon használjuk őket Ennek a szabadságnak egyenes következménye, hogy a világban számtalan számítógép fut például a 172.1601 címmel IP cím ütközés azért nem lép fel közöttük, mert sohasem kerülnek közvetlenül kapcsolatba egymással - kizárólag címfordítás útján érintkezhetnek. A címfordítást például az első részben elemzett NAT biztosíthatja Tipikus hibakeresési zavar, amikor valaki szóvá teszi, hogy belső IP című gépéről nem tud kipingelni, bár minden más zavartalanul működik. Mi a hiba

oka? Semmi Nincs hiba, a NAT-ok, Proxyk a legritkább esetben emelik át az ICMP (Ping) csomagokat. Ne pingeljünk külső címekre 2. Hamis IP címek használata Ritkán fordul elő véletlenül, de praxisomban jött már "szembe" velem olyan hálózati csomag, mely hamis IP címről érkezett. Az IP útválasztás meglepően hasonlít a hagyományos postai kézbesítésre: hamis feladóval éppúgy célbajuttathatunk IP csomagokat, mint postai levelezőlapokat. A postás bácsi csak a címzett címére összpontosít S mint a való életben, a hamis címzés az IP csomag esetében is csak válaszoláskor okoz galibát: hova vigye a postás a személyesen a télapótól kapott levélre írt választlevelemet? Hamisított, de létező feladó (President George W. Bush) esetén pedig a válasz a gyanútlan harmadik félnél köt ki. Kéretlen (válasz)csomagok érkeznek egy gépre? Valószínűleg valahol valaki visszaél a mi IP címünkkel!  Hamis IP címről érkezett

csomagra választ a cím gyanútlan tulajdonosa kap! Volna az IP-ben lehetőség arra is, hogy a hamis IP címről érkező csomag mégis a hamisítóhoz jusson vissza. A megoldás (source routing) lehetővé teszi, hogy egy csomag az eredeti feladó által meghatározott úton jöjjön vissza, hasonlóan az elektronikus levelezés "reply-to” megoldásához. Ezzel a technológiával azonban gyakorlatilag sohasem találkozunk, mert minden jólnevelt útválasztó eldobálja a source routinggal "felszerelt" csomagokat. Hogy miért? Mert az ezzel kapcsolatos hekkelések már évek óta ismertek. A hamis IP cím azonban így is visszaélésekre adhat alkalmat, egyfajta DDoS támadás kivitelezhető vele: ha egyszerre ezer gép áll neki egyetlen másik nevében pingelni össze-vissza a neten, akkor az áldozat (akinek az IP címét felhasználták) a világ minden sarkából elkezd kéretlen ICMP Reply-ket kapni. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás

nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 16 NetAcademia-tudástár  DDoS támadás az áldozat IP címének használatával. (Ez megmagyarázza, miért kap Bush elnök évente több tízezer levelet. :-) Így járt tavaly kora tavasszal a Yahoo!, az e-Bay és a többiek. A nyomozás rendkívül nehéz, ugyanis minden csomag úgy néz ki, mintha valóban az áldozat adta volna fel a ping kérést. Most nem tippeket óhajtottam adni, hanem rávilágítani, hogy mi mindenre "jó" egy kis szemfüles ravaszság, hogyan válik fegyverré minden. Régebben erre azt mondták volna, hogy elsült a kapanyél. Ma csak annyit mondunk: World Trade Center 3. Körkörös routolás A NetMon sorozat egyik részében már kitértem erre a jelenségre, amely akkor fordul elő, ha egy hálózatban az alapértelmezett útvonalak hurkot zárnak be, és egy hálózati csomag olyan címre irányul, amely ismeretlen mindegyi útválasztó előtt. Ebben az esetben ugyanis

mindegyik a 0000 útra küldi az ismeretlen csomagot, mely - digitális jel lévén a végtelenségig keringhetne a hálózatban, ha valaki, vagy valami meg nem fogná Emlékeznek még? A TTL (Time to Live) számláló csökkentése révén az IP csomagok csak egy maximális számú útválasztóátlépésre képesek. Mivel mindegyik router csökkenti a TTL-t, előbb-utóbb ennek értéke nullára fut, s a csomag elhal. Útválasztási protokollok – a Routing Information Protocol Az előző részben eljutottunk odáig, hogy kézzel képesek voltunk módosítani az útválasztók útvonaltábláit. Szép dolog, hibakereséshez kell is ez a tudás, de egy összetett vállalati hálózat útvonalterveinek kiszámításához és megvalósításához nem árt, ha számítógépeinket is segítségül hívjuk. A RIP protokoll telepítsd-és-felejtsd-el módon működik Csak felhajigáljuk a megfelelő gépekre, és a tudás (alhálózatok és átjárók ismerete) szétterjed az egész

hálózatban. Telepítés után még meg kell mondani neki, hogy mely hálókártyákon dolgozzon, és már megy is. A beállítások erdejét lásd később  A RIP telepítése Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 17 NetAcademia-tudástár 2.220/24 Gyönyörűen működik, nem hiába a Xerox találta fel ezt is. Ugyanakkor routerguruk szájából mást hallani: a RIP így nem jó, a RIP úgy nem jó, és nagy hálózatokon teljesen használhatatlan. Most akkor jó, vagy nem jó? Vizsgáljuk meg a működését! Minden router ismeri a belőle kimenő vonalakat, valamint azt az IP címet, amely az adott alhálózaton a gateway (ezt elemezgettük a route print paranccsal). A RIP az útvonalak hosszát az úgynevezett hop counttal méri, mely a route print kimenetében a Metric mező. Ha beteszünk egy hálózati kártyát egy gépbe, azon automatikusan 1-re állítódik a Metric, azaz minden

olyan masina, ami azon a kártyán közvetlenül elérhető, 1 hopra van tőlünk. A Metric nem a bedugaszolt kártya tulajdonsága (bármennyire is annak tűnik), hanem a rajta keresztül elérhető hálóé - így áttételesen az azon található közvetlen szomszédainké is. Most vegyünk fel négy útválasztót az alábbi ábrán látható módon Mi történne, ha ezek elmesélnék egymásnak, mit látnak a világból? RouterA 3.300/16 RouterB 4.440/24 Route Print: 3.300 Metric 1 4.440 Metric 1 2.220 Metric 2 Route Print: 2.220 Metric 1 3.300 Metric 1 4.440 Metric 2 RouterC Route Print: 4.440 Metric 1 3.300 Metric 2 2.220 Metric 3  Három pletykás vénasszony. A vastaggal jelölt sorokat a szomszéd súgta RouterA elmondaná RouterB-nek, hogy lát egy 2.220/24 és egy 3300/16 hálózatot RouterB meghallgatja a történetet, a 3.300/16-ot nem veszi figyelembe, mert azt ő is tudja, de felveszi a 2220/24 hálózatot az útvonaltáblájába, úgy, hogy a Metricet

megnöveli eggyel. Nála a 2220/24 útvonal 2-es Metriccel szerepel majd Ezután pletykás vénasszony módjára továbbmondja RouterC-nek, hogy van ám egy 2.220/24 hálózat tőle 2 hopra, aki immár 3-as Metriccel jegyzi be, hisz a 2.220/24 hálózat tőle már 3 hopra van A RIP-es gépek fix időközönként elküldik egymásnak teljes útvonaltáblájukat, benne saját, és "tanult" (az ábrán vastagított) bejegyzésekkel. Az eredeti RIP alapértelmezésben 30 másodpercenként jelentgeti társainak a saját világképét, mégpedig Broadcast címzéssel, hisz nem tudhatja, hogy egy adott subneten hány érdeklődő akad a bejelentésre. Ez az ő egyik legnagyobb baja Hány géphez jut el a RIP üzenet? Mindhez. És switch esetén? Mindhez A hálózati nyomtatóhoz és a kenyérpirítóhoz is? Igen. Ha egy útvonal megváltozik, akkor a 30 másodperces ütemezésen belül is indulnak úgynevezett triggerelt üzenetek a partnerek felé. Konvergencia A RIP maximum 15 hop

átmérőjű hálózatokhoz való azon egyszerű oknál fogva, hogy a szabvány szerint ami 16 hopra, vagy annál messzebb van, az "unreachable". (Egyes felmérések szerint a földgolyó 17 hoppal bármilyen irányban körbejárható Ennek ellenére a RIP a maga 15 hopos korlátjával csak picike hálózatokra való.) A 15-ös korlátozást azért kellett bevezetni, mert bizonyos hálózati hibákra a RIP igen furcsán reagál: ahelyett hogy egy router kiesését hipp-hopp észrevenné, a lenti ábrához hasonló hálózatban RouterC kiesésével RouterA és RouterB azt fogja hinni, hogy a közvetlen vonal ugyan megszakadt RouterD-hez, de egymás segítségével (RouterA RouterB-n keresztül, RouterB pedig RouterA-n át) mégis eljutnak oda. RouterB ? ? RouterC RouterD RouterA  A világ RouterA szemüvegén keresztül. Egy közbülső útválasztó halála esetén a RIP alternatív útvonalakat vél felfedezni ott is, ahol nincsenek! Ennek a viselkedésnek az az oka,

hogy a RIP mindig a legolcsóbb útvonalat veszi figyelembe, és amíg RouterC élt, addig RouterA a RouterB által ajánlott kerülőutat nem veszi figyelembe. Amint azonban RouterC meghal, mindjárt a 2 hopos, RouterB-n keresztülvezető kerülőút lesz a legolcsóbb, s RouterA figyelembe is veszi – sajnos nem a szakadás győz. És ami a legfurcsább, RouterA és RouterB innentől tanítgatják egymást a rég halott RouterC nemlétező útvonalával. S ahogy egymás fülébe súgják ("te, én azt hallottam, hogy van út RouterD-hez"), mindig hozzáadnak egyet-egyet a hopcounthoz, míg az el nem éri a 16-ot, és akkor VÉGRE kiesik a nemlétező út a pici agyukból. Ezt a jelenséget Counting to Infinitynek hívják, és igen bosszantó, mivel a hálózati hibák észlelése emiatt meglehetősen lassú. A konvergenciaproblémára van megoldás, lásd később. Mérgezett alma Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető

 2000-2003, NetAcademia Kft 18 NetAcademia-tudástár A RIP eredeti verzóját azonban nem a broadcastolás és a lassú konvergencia miatt felejthetjük el, hanem a boldog békeidők miatt. Amikor ez a szabvány készült ([1], 1988), még nem voltak fogyóban az IP címek, és senki sem gondolt arra, hogy egyszer majd az A, B és C osztályú IP címtartományokat a subnet mask bitjeinek beállítgatásával ripityára fogjuk szabdalni (lásd CIDR, azaz Classless InterDomain Routing, [3]). Íme a RIP csomag felépítése: command version must be zero Address family identifier must be zero IP address must be zero must be zero metric (az utóbbi négy sor ismétlődik max. 25-ször) A RIP eredeti verziójában kérem szépen nem szerepel a routerek közötti forgalomban az egyes hálózatok subnet maskja! De hisz ez így használhatatlan! RIP v2 1994-ben látott napvilágot a RIP második verziója [2], mely már figyelembe veszi a CIDR-helyzetet, nem csak Broadcastolni tud,

hanem Multicasttal is képes értesíteni a többi routert, továbbá némi szekuriti is van benne - no nem túl sok, egy kevés klírtext jelszó "védelem". Az a döbbenetes a RIPv2 csomagformátumában, hogy annak dacára, hogy csomó mást is tartalmaz, mint amiről a RIPv1 valaha is álmodott, kompatibilis az előddel, azaz RIPv2 csomagokból RIPv1 útválasztók tanulhatnak! Az IP cím utáni „must be zero” mező viszi a subnet maskot. Ez a gyönyörű az Internetben: a zökkenőmentes haladás, és az elődök szellemének tiszteletben tartása. Az új RIP, mint említettük, Multicastolni is tud, mégpedig a 224009 címen. Az alábbi ábrán – egy kis csalással – megjelenítettem az RRAS-féle RIPv2 Interface tulajdonságlapjának első oldalán az összes beállítást. A csalás lényege, hogy egyszerre sikerült legördítenem az összes kombót Ezt csinálja utánam valaki!  A RIPv2 beállításai • • Operation mode: ez a görgettyű állítja

be, hogy RIP routerünk részt vegyen-e a 30 másodpercenkénti periodikus üzenetküldésben. Auto-static update módban csak és kizárólag RIP Requestekre válaszol, Periodic Update módban önként elárulja minden titkát Outgoing packet control: itt lehet beállítani, hogy - ha egyáltalán megszólal - hogyan tegye. RIPv1 nyelven csak Broadcastolni tud, és ne feledjük, búcsút mondhatunk a subnet mask átvitelnek. RIPv2-ül már két módon (Broad és Multicast) beszélhet, míg a Silent RIP azt jelenti, hogy csak hallgatózik és tanul, de senkinek nem mond semmit. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 19 NetAcademia-tudástár Incoming packet control: mely bejövő csomagtípusokra reagáljon. Added cost for routes: ennyit ad hozzá a beérkező útvonalak hop countjához (Metric) mielőtt beveszi az útvonaltáblába • Tag for announced routes: itt két bájtunk van, ahova bármit

beírhatunk. Eredetileg a RIP üzenet forrásának tipizálására való (külső-belső) de jobbára semmire sem használjuk. • Activate authentication: egyfajta hamis biztonságérzetet adhat ez a jelszómező. Minden RIPv2 útválasztón egyformán kell kitölteni – ha kitöltjük egyáltalán. Arra való, hogy csak a jelszó birtokosaival replikáljon routerünk Csakhogy a jelszó klírtext, vagy más néven ASCII titkosítással (értsd: olvashatóan) kerül ki a hálóra. Nem sok értelme van Ennél sokkal többet ér a Security és a Neighbors fül, ahol explicite be lehet állítani, hogy kiknek küld, kiktől fogad, mely útvonalakat tesszük esetleg tiltólistára, hogy még véletlenül se íródjanak felül. És végül az Advanced fül: • •  A RIP matematikája • Periodic announcement interval: itt módosíthatjuk esetleg az alapértelmezett 30 másodpercenkénti értesítéseket (nem ajánlott). • Time before routes expire: ez a szám az

útvonalbejegyzések TTL-je. Ha ennyi másodpercig nem frissíti a partner, érvénytelennek kell tekinteni. Azonban ekkor még nem törlődik, hanem mint „érvénytelen” kerül továbbadásra, hogy a többi partner is érvényteleníthesse • Time before route is removed: a végleges törlés késleltetése A most következő két pipa külön alfejezetet érdemel. Emlékszünk még az egymást hülyeséggel traktáló RouterA és RouterB esetére? Az útvonaltáblák trükkös továbbításával elkerülhető lenne ez a helyzet. Erről szól a horizontvonal, és a mérgezett alma. Split horizon és poisoned update Nagyon egyszerű elmagyarázni a horizontvonal-trükköt: az ezzel a beállítással futó RIP routerek nyilvántartják, hogy melyik útvonalat kitől tanulták. Ha csak ezt pipáljuk be, úgy kürtölik szét tudásukat, hogy a tanítónak sohasem feleselnek vissza Vagyis ha RouterA éppen RouterB-től tanult valamit, akkor azt az útvonalat oda nem mondja vissza.

Ezzel elkerülhető egymás fokozatos elléptetése 16 hopig, amikor is végre megáll az őrültség (elérjük a végtelent. ∞ = 16) Ez a trükk kiegészíthető a mérgezett almával (poisoned update). Ekkora tanuló visszamondja a leckét a tanítónak, de úgy, hogy „amit tőled tanultam az nem létezik”, vagyis minden megtanult útvonalat 16-os Metriccel, azaz elérhetetlenként mond vissza (a végtelen ugye elérhetetlen?) Mindaddig, amíg az eredeti út létezik, ez a mérgezett visszafeleselés nem változtat semmit a működésen, mert a tanár az eredeti útvonalat tekinti érvényesnek, hisz az nyilván közelebb van, mint amit a nebuló állít. Amint azonban RouterC meghal, és az eredeti útvonal megszakad, a nebuló által közölt végtelen lesz a legközelebbi út, s nem egyenként lépkedve érik el a 16-ot, hanem „azonnal”. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 20

NetAcademia-tudástár Összegzés Minden problémája ellenére használjuk bátran a RIP protokollt kis és közepes hálózatokon, mert a telepítsd-és-felejtsd-el működés iszonyatos mértékben csökkenti a TCO-t. RIP: amivel nem kell foglalkozni! Csak működik és kész Menthetetlen hátrányai: • Nagyobb hálózatokban (10-12 hop) az azonnali konvergencia percekig tart • Vannak olyan – ismert és elkerülendő - hálózati topológiák, ahol nem használható, mert hurkot csinál • Nagy hálózatok esetén (alhálók száma > 25) elég jelentősen nő az egyébként minimális sávszélességigénye, mert komplett útvonaltáblákkal dobálódzik Miért? Van más? Van bizony! Vannaok olyan útválasztó protokollok, melyek tetszőleges nagyságú hálózatra alkalmazhatók, nem a komplett útvonaltáblát küldik szét, csak a vonalak állapotinformációit (link state), amelyek mindig pillanatok alatt konvergálnak, amelyek sohasem hoznak létre hurkot, amelyek

esetén kolbászból van a kerítés. Az egyik ilyen ütőképes protokoll az OSPF (Open Shortest Path First), mellyel a következő RRAS cikkben foglalkozom részletesebben. Addig is egy kis fejtörő: ha az OSPF annyival jobb, mint a RIP, miért nem mindig azt használjuk? Megfejtés. Mert az OSPF: • bevezetése tervezést igényel (a hálózatot mérettől függően Area-kra kell bontani) • bonyolult matematikán alapul, amit ha érteni nem is kell, de a létezésének felismeréséig el kell jutni • nem csökkenti a TCO-t, azaz telepítés után is pátyolgatást igényel(het) • a bonyolult matekozás miatt sok memóriát és processzoridőt igényel(het) Fóti Marcell marcellf@netacademia.net MCSE, MCT, MCDBA, MZ/X A cikkben szereplő URL-ek: [1] A RIP prorokoll. RFC 1085 [2] A RIP version 2. RFC 1723 [3] CIDR (Classless InterDomain Routing) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 21