Ma megkezdjük az OSPF protokollal kapcsolatos ismerkedést. Ez a téma, akárcsak az EIGRP protokoll áttekintése, az egyik legfontosabb a CCNA kurzusban. Ahogy látjátok, a 2.4-es szakasz címe: „Az OSPFv2 egyedi zónájának és többzónás konfigurálása, ellenőrzése és hibaelhárítása IPv4 protokoll esetén (kivétel az autentikáció, szűrés, kézi útvonalösszegzés, újraelosztás, aknamező, virtuális hálózat és LSA)”.
Az OSPF téma elég széles terjedelmű, így 2, esetleg 3 videoleckét is igénybe vesz. A mai lecke a téma elméleti oldalára összpontosít, bemutatom, hogy általában mit jelent ez a protokoll és hogyan működik. A következő videóban átérünk az OSPF konfigurációs módjára a Packet Tracer segítségével.
Tehát ezen a leckén három dolgot fogunk megvizsgálni: mi az OSPF, hogyan működik és mi az OSPF zónák. Az előző lecke során beszéltünk arról, hogy az OSPF egy linkállapot típusú forgalmazási protokoll, amely a routerek közötti kapcsolatokat megvizsgálva döntéseket hoz a csatornák sebessége alapján. A hosszú csatornák nagyobb sebességgel, azaz nagyobb sávszélességgel prioritást élveznek a rövid csatornákkal szemben, amelyek alacsonyabb sávszélességgel rendelkeznek.
A RIP protokoll mint távolsági vektort választ egy hopos utat, még ha ez a csatorna alacsony sebességű is, míg az OSPF hosszú utat választ több hopon keresztül, ha az ezen az útvonalon lévő összsebesség magasabb, mint a rövid útvonal forgalma.
Később megvizsgáljuk a döntéshozatali algoritmust, addig is meg kell jegyeznetek, hogy az OSPF egy linkállapot protokoll. Ezt a nyílt szabványt 1988-ban hozták létre, így minden hálózati eszköz gyártója és szolgáltatója által felhasználható volt. Ezért az OSPF lényegesen népszerűbb, mint az EIGRP.
Az OSPF 2-es verziója csak az IPv4 protokollt támogatja, míg egy évvel később, 1989-ben, a fejlesztők bejelentették a 3. verzió megjelenését, amely támogatja az IPv6-ot. Azonban a teljes funkcionalitású harmadik OSPF verzió IPv6-ra csak 2008-ban jelent meg. Miért az OSPF lett a választás? Az utolsó leckénk során megtudhattuk, hogy ez a belső átjáró protokoll sokkal gyorsabban végzi el az útvonalak konvergenciáját, mint a RIP. Ez egy osztály nélküli protokoll.
Ha emlékszel, a RIP osztályalapú protokoll, ami azt jelenti, hogy nem küld információt a hálózati maszkjáról, és ha találkozik egy A osztályú IP-címmel /24, akkor azt nem fogadja el. Például ha megadod neki a 10.1.1.0/24 IP-címet, akkor azt 10.0.0.0-ként értelmezi, mert nem érti, amikor a hálózatot több alhálózatra bontják egyetlen hálózati maszkkal.
Az OSPF egy biztonságos protokoll. Például, ha két router OSPF információt cserél, beállíthatod az hitelesítést úgy, hogy az információt csak a jelszó megadása után oszthassák meg a szomszédos routerrel. Ahogy már említettük, ez egy nyílt szabvány, ezért az OSPF-t sok hálózati eszköz gyártója használja.
Globális értelemben az OSPF a Link State Advertisement (LSA) hirdetések cseréjének mechanizmusát jelenti. Az LSA üzeneteket a router generálja, és sok információt tartalmaznak: a router egyedi azonosítóját (router-id), a router által ismert hálózatok adatait, azok költségét és így tovább. Mindezek az információk szükségesek a router számára a routing döntések meghozatalához.
A router R3 LSA információját a R5 routernek küldi, míg a R5 router a saját LSA információját osztja meg a R3-mal. Ezek az LSA-k egy adatstruktúrát alkotnak, amely létrehozza a Link State Data Base-t (LSDB). A router összegyűjti az összes kapott LSA-t, és elhelyezi őket a saját LSDB-jében. Miután mindkét router létrehozta a saját adatbázisát, Hello üzeneteket cserélnek, amelyek a szomszédok felfedezésére szolgálnak, és elkezdik az LSDB-jük összehasonlításának eljárását.
A R3 router DBD üzenetet küld a R5 routernek, amely az 'adatbázis leírása', míg a R5 visszaküldi a saját DBD-jét a R3-nak. Ezek az üzenetek tartalmazzák azokat az LSA indexeket, amelyek a routerek adatbázisaiban megtalálhatók. A DBD megérkezése után a R3 router hálózati állapotkérést (LSR) küld a R5 routernek, amely így szól: 'már van 3, 4 és 9 üzenetem, ezért kérlek, küldd el nekem csak az 5-öt és 7-et.'
Ugyanígy jár el az R5, amikor a harmadik routernek ezt mondja: „van információm 3, 4 és 9, ezért küldj nekem 1-et és 2-t”. A LSR kérések megérkezésekor a routerek visszaküldik a hálózati állapotfrissítő csomagokat (LSU), tehát a harmadik router az R5 routertől kap LSU-t a saját LSR-re. Miután a routerek frissítik az adatbázisaikat, mindegyikük, még ha 100 routerük is van, azonos LSDB adatbázissal fog rendelkezni. Amint a routerek létrehozzák az LSDB adatbázisokat, mindegyikük tudni fog az egész hálózatról. Az OSPF protokoll a Legrövidebb Út Első (Shortest Path First) algoritmust használja a routing táblák létrehozásához, ezért a helyes működés legfontosabb feltétele az összes eszköz LSDB-jének szinkronizálása a hálózatban.
A bemutatott ábrán 9 router található, akik mindegyike LSR, LSU és hasonló üzeneteket cserél a szomszédaival. Mindannyian p2p, vagyis „pont-pont” interfészeken keresztül vannak összekötve, amelyek támogatják az OSPF protokoll munkáját, és kölcsönhatásba lépnek egymással az azonos LSDB-k létrehozásának céljából.
Amint az adatbázisok szinkronizálva vannak, minden router a legrövidebb út algoritmusát használva megalkotja a saját routing tábláját. A különböző routerek táblái eltérnek egymástól. Tehát minden router azonos LSDB-t használ, de a routing táblázatokat saját elképzelései alapján alakítja ki a legrövidebb utakról. Az OSPF rendszerének állandó LSDB frissítésekre van szüksége ezen algoritmus alkalmazásához.
Tehát az OSPF működéséhez előbb három feltételt kell biztosítani: megtalálni a szomszédokat, létrehozni és frissíteni az LSDB-t, és megalkotni a routing táblát. Az első feltétel teljesítéséhez a hálózati adminisztrátornak esetleg manuálisan kell konfigurálnia a router-id-t, az időzítéseket vagy a wildcard maszkot. A következő videóban megnézzük az OSPF működéséhez szükséges eszköz beállításait, addig is tudnod kell, hogy ez a protokoll visszafordított maszkot használ, és ha ez nem egyezik, ha az alhálózataid nem egyeznek, vagy ha az azonosítás nem megfelelő, a routerek közötti szomszédság nem jöhet létre. Ezért az OSPF hibakeresése során meg kell állapítanod, hogy miért nem jön létre ez a szomszédság, azaz ellenőrizd a fent említett paraméterek egyezését.
Hálózati adminisztrátor lévén nem vesz részt az LSDB létrehozási folyamatában. Az adatbázisok frissítése automatikusan történik meg a routerek szomszédságának létrejötte után, akárcsak az útvonalválasztási táblák felépítése. Ezt mind elvégzi az eszköz, amelyet az OSPF protokoll használatára állítottak be.
Nézzünk meg egy példát. Van két routerünk, amelyeknek az azonosítóit RID 1.1.1.1 és 2.2.2.2-ra állítottam. Amint összekapcsoljuk őket, a link azonnal up állapotba kerül, mert először beállítottam ezeket a routereket OSPF használatára. Amint a kapcsolat létrejön, az A router azonnal elküldi a Hello csomagot a másiknak. Ebben a csomagban található információ arról, hogy ez a router még senkit nem "látott" ezen a csatornán, mivel először küldi a Hellot, valamint a saját azonosítóját, a csatlakoztatott hálózatról szóló adatokat és egyéb információkat, amelyeket megoszthat a szomszédjával.
Amikor a B router megkapja ezt a csomagot, azt mondja: "Látom, hogy ezen a kapcsolatban van egy potenciális szomszéd az OSPF protokoll szerint", majd átkerül az Init állapotba. A Hello csomag nem unicast vagy broadcast üzenet, hanem multicast csomag, amely a multicast OSPF IP-címre (224.0.0.5) van küldve. Néhányan azt kérdezik, mi a multicast alhálózati maszkja. Az igazság az, hogy a multicastnak nincs alhálózati maszkja, mint egy rádiójel, amit minden olyan eszköz hall, amely a frekvenciáján van beállítva. Például, ha szeretné hallani az FM rádiót, amely a 91,0 frekvencián sugároz, akkor be kell állítania a rádiót ezen a frekvencián.
Hasonlóképpen, a B router be van állítva arra, hogy üzeneteket fogadjon a 224.0.0.5 multicast címre. E csatorna hallgatásával megkapja a Hello csomagot, amelyet az A router küldött, és válaszol az üzenetével.
Ezért a szomszédság csak akkor állapítható meg, ha a B válasza megfelel egy sor kritériumnak. Az első kritérium – a Hello üzenetek küldési gyakorisága és a válaszra várakozási idő (Dead Interval) mindkét router esetében meg kell, hogy egyezzen. Általában a Dead Interval több Hello időzítő értéknek felel meg. Így ha az A router Hello időzítője 10 másodperc, és a B router 30 másodperc múlva küldi el neki az üzenetét, miközben a Dead Interval 20 másodperc, a szomszédság nem jön létre.
A második kritérium, hogy mindkét routernek azonos típusú hitelesítést kell használnia. Ennek megfelelően a hitelesítési jelszavaknak is egyezniük kell.
A harmadik kritérium az Arial ID zónaazonosítók egyezése, a negyedik pedig a hálózati prefix hossza. Ha az A router \/24 prefixet jelez, akkor a B routernek is \/24 hálózati prefixszel kell rendelkeznie. A következő videóban ezt részletesebben megvizsgáljuk, de egyelőre megjegyzem, hogy ez nem alhálózati maszk; itt a routerek visszafelé maszkot, azaz Wildcard maszkot használnak. Természetesen a Stub area zónák zászlóinak is egyezniük kell, ha a routerek ebben a zónában helyezkednek el.
Ezeknek a kritériumoknak a ellenőrzése után, ha megfelelnek, a B router elküldi az A routernek a Hello csomagját. Ezzel szemben az A üzenetével a B router jelzi, hogy látta az A routert, és bemutatkozik.
Erre a válaszüzenetre az A router ismét Hello-t küld a B-nek, amelyben megerősíti, hogy ő is látta a B routert, a közöttük lévő kommunikációs csatorna az 1.1.1.1 és 2.2.2.2 eszközökből áll, ő maga pedig az 1.1.1.1 eszköz. Ez a szomszédság létrehozásának nagyon fontos szakasza. Ebben az esetben kéthelyi kapcsolatot használnak (2-WAY), de mi történik, ha van egy switchünk egy 4 routerből álló elosztott hálózattal? Ebben a „megossztott” környezetben az egyik routernek kiemelt routerként (Designated router, D.R) kell szerepelnie, míg a másik egy tartalék kiemelt router (Backup designated router, B.D.R) szerepét tölti be.
Mindegyik eszköz Full connection-t, vagyis teljes szomszédsági állapotot alakít ki, ami később részletesen átbeszélésre kerül, azonban ez a kapcsolat csak a D.R-ral és a B.D.R-ral fog létrejönni, a két alsó router (D és B) továbbra is point-to-point kéthelyi kapcsolaton fognak kommunikálni.
Ez azt jelenti, hogy a D.R-ral és B.D.R-ral minden router teljes szomszédsági kapcsolatot alakít ki, míg egymás között point-to-point kapcsolatot létesítenek. Ez nagyon fontos, mert kéthelyi kapcsolat esetén a Hello csomag minden paraméterének meg kell egyeznie. Az esetünkben minden egyezik, így az eszközök probléma nélkül alakulnak szomszédságba.
Miután a kétirányú kapcsolat létrejött, A router egy Database Description csomagot küld B routernek, és átvált ExStart állapotba – a cserék kezdetére, vagy a betöltés várakozására. A Database Descriptor információt szolgáltat, hasonlóan egy könyv tartalomjegyzékéhez – ez felsorolja mindazt, ami a routing adatbázisban található. Válaszként B router elküldi a saját Database Description-jét A routernek, és átvált Exchange állapotba az adatcsere részleteiről. Ha az Exchange állapotban a router észleli, hogy a routing adatbázisából hiányzik valamilyen információ, akkor átvált LOADING állapotba, és elkezdi megosztani az LSR, LSU és LSA üzeneteket a szomszédjával.
Tehát A router elküldi a szomszédjának LSR-t, aki LSU csomagot küld vissza, amire A router válaszol B routernek LSA üzenettel. Ez az adatcsere annyiszor történik meg, ahányszor a készülékek szeretnék megosztani az LSA üzeneteket. A LOADING állapot azt jelenti, hogy az LSA adatbázis teljes frissítése még nem történt meg. Miután minden adatot betöltöttek, mindkét eszköz átvált FULL szomszédsági állapotba.
Megjegyzem, hogy a kétirányú kapcsolattal rendelkező eszközök egyszerűen szomszédsági állapotban vannak, míg a teljes szomszédsági állapot csak routerek között lehetséges, D.R. és B.D.R. között. Ez azt jelenti, hogy minden router tájékoztatja D.R.-t a hálózati változásokról, és minden router D.R.-től értesül ezekről a változásokról.
A D.R. és B.D.R. kiválasztása fontos kérdés. Nézzük meg, hogyan zajlik a D.R. választása egy általános környezetben. Tegyük fel, hogy a rendszerünkben három router és egy switch található. Először az OSPF eszközök összehasonlítják a prioritást a Hello üzenetekben, majd összehasonlítják a Router ID-t.
A legmagasabb prioritással rendelkező eszköz lesz D.R. Ha két eszköz prioritása megegyezik, akkor közülük az a készülék lesz D.R., amelyiknek a legmagasabb Router ID-je van.
A B.D.R. tartalék dedikált router a második legfontosabb prioritással rendelkező eszköz vagy a második legmagasabb Router ID-vel rendelkező eszköz lesz. Ha a D.R. meghibásodik, azt azonnal helyettesíti a B.D.R. Ő fog D.R. szerepet játszani és a rendszer kiválaszt egy másik B.D.R.-t.
Remélem, megértetted a D.R. és B.D.R. választását; ha nem, akkor még visszatérek erre a kérdésre egy következő videóban és elmagyarázom ezt a folyamatot.
Tehát áttekintettük, hogy mit jelentenek a Hello, az adatbázis leírása (Database Descriptor) és az LSR, LSU és LSA üzenetek. Mielőtt áttérnénk a következő témára, beszéljünk egy kicsit az OSPF költségeiről.
A Cisco-nál a útvonal költségét a referencia sávszélesség (Reference bandwidth) és a csatorna költsége közötti hányados képlete alapján számítják. Például, ha az eszközök egy soros porton keresztül csatlakoznak, a sebesség 1.544 Mbit/s, így a költség 64. Ethernet kapcsolat esetén 10 Mbit/s sebességnél a költség 10, míg a 100 Mbit/s sebességű FastEthernet kapcsolat költsége 1 lesz.
Gigabit Ethernet használatakor a sebesség 1000 Mbit/s, azonban itt a sebességet mindig 1-nek tekintjük. Ha a hálózatban van Gigabit Ethernet, a Ref. BW alapértelmezett értékét 1000-re kell módosítani. Ebben az esetben a költség 1 lesz, és az összes költségérték tízszeresére nő. Miután kialakítottuk a szomszédságot és a LSDB adatbázist, áttérünk a routing táblázat felépítésére.
Miután megkaptuk az LSDB-t, minden router önállóan elindítja az útvonalak listájának létrehozását az SPF algoritmus segítségével. A mi esetünkben az A router önmaga számára így fogja létrehozni a táblázatot. Például kiszámítja az A-R1 útvonal költségét, és azt 10-re állapítja meg. A séma egyszerűsítése érdekében tegyük fel, hogy az A router meghatározza az optimális útvonalat a B routerhez. Az A-R1 kapcsolat költsége 10, az A-R2 kapcsolat 100, míg az A-R3 költsége 11, ami az A-R1 (10) és R1-R3 (1) útvonalak összegének felel meg.
Ha az A router el szeretne jutni az R4 routerhez, akkor ezt megteheti az A-R1-R4 vagy az A-R2-R4 útvonalon, és mindkét esetben az útvonalak költsége ugyanaz lesz: 10+100 = 100+10 = 110. Az A-R6 útvonal költsége 100+1 = 101, ami már kedvezőbb. Ezután az R5 routerhez vezető útvonalat vizsgáljuk az A-R1-R3-R5 útvonalon, melynek költsége 10+1+100 = 111 lesz.
Az R7 routerhez két útvonalon lehet eljutni: A-R1-R4-R7 vagy A-R2-R6-R7. Az első költsége 210, a másodiké 201, tehát a 201-es útvonalat kell választani. Tehát, hogy elérje a B routert, az A router 4 útvonalat használhat.
Az A-R1-R3-R5-B útvonal költsége 121 lesz. Az A-R1-R4-R7-B útvonal ára 220. Az A-R2-R4-R7-B 210-be kerül, míg az A-R2-R6-R7-B ára 211. Ennek alapján az A router a legkisebb költségű, 121-es útvonalat választja, és ezt helyezi a routing táblába. Ez egy nagyon leegyszerűsített ábrázolása az SPF algoritmus működésének. Valójában a táblázatba nemcsak az optimalizált útvonalat képező routerek azonosítói, hanem az őket összekötő portok azonosítói és minden egyéb szükséges információ is bekerül.
Nézzünk meg egy újabb témát, amely a routing zónákra vonatkozik. Általában az OSPF eszközök konfigurálásakor mindegyikük egy közös zónában helyezkedik el.
Mi történik, ha egy, az R3 routerhez csatlakozó eszköz hirtelen meghibásodik? Az R3 router azonnal elkezdi elküldeni az R5 és R1 routereknek a üzenetet, hogy a kapcsolat az adott eszközzel már nem működik, és minden router frissítéseket kezd el cserélni erről az eseményről.
Ha 100 routered van, mind frissíteni fogja a kapcsolatállapotot, mert egy közös zónában találkoznak. Ugyanez fog történni, ha az egyik szomszédos router meghibásodik – minden eszköz a zónában LSA frissítéseket cserél. A frissítések után megváltozik a hálózat topológiája. Amint ez megtörténik, az SPF újraszámítja a routing táblákat a megváltozott körülményeknek megfelelően. Ez egy nagyon terjedelmes folyamat, és ha egy zónában ezer eszköz található, akkor nyomon kell követned a routerek memóriájának méretét, hogy elegendő legyen az összes LSA és az LSDB óriási adatbázisának tárolására. Ha bármely területen változások történnek a zónában, az SPF algoritmus azonnal újraszámítja az útvonalakat. Alapértelmezés szerint az LSA minden 30 percben frissül. Ez a folyamat nem egyszerre zajlik le minden eszközön, azonban minden esetben minden router 30 percenként hajtja végre a frissítéseket. Minél több hálózati eszköz van, annál több memória és idő szükséges az LSDB frissítéséhez.
A problémát úgy lehet megoldani, ha egy közös zónát több különálló zónára osztunk, azaz több zónás megoldást alkalmazunk. Ehhez szükség van egy tervre vagy a teljes hálózat diagramjára, amellyel dolgozik. A nullás zóna, AREA 0, az Ön fő zónája, a Main area. Ez az a hely, ahol a csatlakozás történik a külső hálózathoz, például az internethez. Új zónák létrehozásakor arra kell figyelni, hogy minden zónában legyen egy terület határoló router, az ABR. A határoló routernek egy interfésze van az egyik zónában, a másik interfésze pedig egy másik zónában. Például az R5 router interfészei az 1-es zónában és a 0-ás zónában találhatók. Ahogy említettem, minden zónának csatlakoznia kell a nullás zónához, azaz rendelkeznie kell egy határoló routerrel, amelynek egyik interfésze az AREA 0-hoz csatlakozik.
Tegyük fel, hogy az R6-R7 kapcsolata megszakadt. Ekkor az LSA frissítése csak az AREA 1 zónában fog terjedni, és csak ezt a zónát érinti. A 2-es zónában és a 0-ás zónában lévő eszközök ezt még csak nem is tudják. Az R5 határoló router összegzi az információkat arról, ami a zónájában történik, és egy összegzett hálózati állapot információt küld a fő zónába, az AREA 0-ba. Az egy zónában lévő eszközöknek nem kell tudniuk az összes LSA változásról a más zónákban, mert az ABR router összegzett információkat fog továbbítani az útvonalakról egyik zónából a másikba.
Ha nem egészen érti a zónák fogalmát, akkor többet tudhat meg a következő leckék során, amikor az OSPF irányítás beállításával és néhány példával foglalkozunk.
Köszönjük, hogy velünk maradnak. Tetszenek Önöknek a cikkeink? Szeretnének több érdekes anyagot látni? Támogassanak minket rendelés leadásával vagy ismerősöknek való ajánlással. 30% kedvezmény a Habr felhasználóinak az egyedülálló entry-level szervereinkre, amelyet Önöknek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd két alkalommal olcsóbban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
