Ma elkezdjük megismerni az OSPF útválasztást. Ez a téma az EIGRP protokollhoz hasonlóan a legfontosabb téma az egész CCNA kurzusban. Mint láthatja, a 2.4. szakasz címe: „OSPFv2 egyzónás és többzónás konfigurálása, tesztelése és hibaelhárítása IPv4-hez (kivéve a hitelesítést, a szűrést, a kézi útvonal-összegzést, az újraelosztást, a csonkterületet, a virtuális hálózatot és az LSA-t).”
Az OSPF témája meglehetősen kiterjedt, így 2, esetleg 3 videóleckét igényel. A mai leckét a kérdés elméleti oldalának szenteljük; elmondom, mi ez a protokoll általánosságban, és hogyan működik. A következő videóban áttérünk az OSPF konfigurációs módra a Packet Tracer segítségével.
Tehát ebben a leckében három dologgal foglalkozunk: mi az OSPF, hogyan működik és mik azok az OSPF zónák. Az előző leckében azt mondtuk, hogy az OSPF egy Link State routing protokoll, amely megvizsgálja az útválasztók közötti kommunikációs kapcsolatokat, és a kapcsolatok sebessége alapján hoz döntéseket. A nagyobb sebességű, azaz nagyobb áteresztőképességű hosszú csatorna elsőbbséget élvez a kisebb áteresztőképességű rövid csatornával szemben.
A RIP protokoll távolságvektor protokollként egyugrásos útvonalat választ, még akkor is, ha ennek a kapcsolatnak kicsi a sebessége, és az OSPF protokoll egy hosszú, több ugrásból álló útvonalat választ, ha ezen az útvonalon a teljes sebesség nagyobb, mint a forgalom sebessége a rövid úton.
Később megnézzük a döntési algoritmust, de most ne feledje, hogy az OSPF egy Link State Protocol. Ezt a nyílt szabványt 1988-ban hozták létre, így minden hálózati berendezés gyártója és bármely hálózati szolgáltató használhatja. Ezért az OSPF sokkal népszerűbb, mint az EIGRP.
Az OSPF 2-es verziója csak az IPv4-et támogatta, majd egy évvel később, 1989-ben a fejlesztők bejelentették a 3-as verziót, amely támogatta az IPv6-ot. Az IPv6-hoz készült OSPF teljesen működőképes harmadik verziója azonban csak 2008-ban jelent meg. Miért az OSPF-et választottad? Az utolsó leckében megtanultuk, hogy ez a belső átjáró protokoll sokkal gyorsabban hajtja végre az útvonalkonvergenciát, mint a RIP. Ez egy osztály nélküli protokoll.
Ha emlékszel, a RIP egy osztályozott protokoll, vagyis nem küld alhálózati maszk információt, és ha A/24 osztályú IP-címmel találkozik, nem fogadja el. Ha például 10.1.1.0/24-es IP-címmel jeleníti meg, akkor a 10.0.0.0-s hálózatként fogja fel, mert nem érti, ha egy hálózat egynél több alhálózati maszkot használ alhálózatba.
Az OSPF egy biztonságos protokoll. Például, ha két útválasztó OSPF információkat cserél, beállíthatja a hitelesítést úgy, hogy csak jelszó megadása után tudjon információkat megosztani a szomszédos útválasztóval. Mint már említettük, ez egy nyílt szabvány, így az OSPF-et számos hálózati berendezés gyártója használja.
Globális értelemben az OSPF a Link State Advertisements vagy LSA-k cseréjének mechanizmusa. Az LSA-üzeneteket az útválasztó generálja, és sok információt tartalmaznak: a router egyedi azonosítóját, a router-azonosítót, a router által ismert hálózatokra vonatkozó adatokat, azok költségét stb. Az útválasztónak mindezekre az információkra szüksége van az útválasztási döntések meghozatalához.
Az R3 útválasztó elküldi az LSA információit az R5 útválasztónak, az R5 útválasztó pedig megosztja az LSA információit az R3-mal. Ezek az LSA-k jelentik a kapcsolatállapot-adatbázist vagy LSDB-t alkotó adatstruktúrát. Az útválasztó összegyűjti az összes fogadott LSA-t, és elhelyezi azokat az LSDB-jében. Miután mindkét útválasztó létrehozta az adatbázisát, Hello-üzeneteket cserél, amelyek a szomszédok felfedezésére szolgálnak, és megkezdik az LSDB-k összehasonlítását.
Az R3 router DBD-t vagy „adatbázisleírás” üzenetet küld az R5 útválasztónak, az R5 pedig a DBD-t az R3 útválasztónak. Ezek az üzenetek LSA indexeket tartalmaznak, amelyek elérhetők az egyes útválasztók adatbázisaiban. Miután megkapta a DBD-t, az R3 egy LSR hálózati állapotkérést küld az R5-nek, mondván: „Már van a 3,4-as, 9-es és 5-es üzenetem, ezért csak az 7-ös és a XNUMX-es üzenetet küldje el.”
Az R5 ugyanezt teszi, és azt mondja a harmadik útválasztónak: „Van információm a 3,4-as, 9-es és 1-es adatokról, ezért küldje el nekem az 2-et és a 5-t.” Miután megkapták az LSR kéréseket, az útválasztók visszaküldik az LSU hálózati állapotfrissítési csomagokat, azaz válaszul az LSR-re a harmadik útválasztó kap egy LSU-t az R100 útválasztótól. Miután az útválasztók frissítették az adatbázisaikat, mindegyiknek ugyanaz az LSDB-je lesz, még ha XNUMX útválasztója is van. Miután az LSDB adatbázisok létrejöttek az útválasztókban, mindegyik tudni fogja a teljes hálózat egészét. Az OSPF protokoll a Shortest Path First algoritmust használja az útválasztási tábla létrehozásához, így helyes működésének legfontosabb feltétele, hogy a hálózaton lévő összes eszköz LSDB-je szinkronban legyen.
A fenti diagramon 9 útválasztó található, amelyek mindegyike LSR, LSU és így tovább üzeneteket cserél a szomszédaival. Mindegyikük p2p-n vagy „pont-pont” interfészen keresztül kapcsolódik egymáshoz, amelyek támogatják az OSPF protokollon keresztüli működést, és kölcsönhatásba lépnek egymással, hogy létrehozzák ugyanazt az LSDB-t.
Amint a bázisok szinkronizálva vannak, minden útválasztó a legrövidebb út algoritmusával létrehozza a saját útválasztási táblázatát. Ezek a táblázatok eltérőek lesznek a különböző útválasztókhoz. Vagyis minden útválasztó ugyanazt az LSDB-t használja, de a legrövidebb útvonalakra vonatkozó saját megfontolásai alapján hoz létre útválasztási táblákat. Az algoritmus használatához az OSPF-nek rendszeresen frissítenie kell az LSDB-t.
Tehát ahhoz, hogy az OSPF önmagában működjön, először 3 feltételt kell biztosítania: szomszédokat kell keresnie, létrehozni és frissíteni az LSDB-t, és létrehozni egy útválasztási táblát. Az első feltétel teljesítéséhez előfordulhat, hogy a hálózati rendszergazdának manuálisan be kell állítania az útválasztó azonosítóját, az időzítéseket vagy a helyettesítő karaktermaszkot. A következő videóban egy eszköz beállítását fogjuk megvizsgálni, hogy működjön az OSPF, egyelőre tudnia kell, hogy ez a protokoll fordított maszkot használ, és ha nem egyezik, az alhálózatok nem egyeznek, vagy a hitelesítés nem egyezik , az útválasztók környéke nem tud kialakulni. Ezért az OSPF hibaelhárítása során meg kell találnia, hogy miért nem ez a szomszédság jön létre, vagyis ellenőrizze, hogy a fenti paraméterek egyeznek-e.
Hálózati rendszergazdaként Ön nem vesz részt az LSDB létrehozási folyamatában. Az adatbázisok automatikusan frissülnek az útválasztók környezetének létrehozása után, csakúgy, mint az útválasztó táblák felépítése. Mindezt maga az eszköz hajtja végre, úgy konfigurálva, hogy az OSPF protokollal működjön.
Nézzünk egy példát. 2 routerünk van, amelyekhez az egyszerűség kedvéért 1.1.1.1 és 2.2.2.2 RID-eket rendeltem. Amint csatlakoztatjuk őket, a linkcsatorna azonnal up állapotba kerül, mert ezeket a routereket először úgy konfiguráltam, hogy OSPF-el működjenek. Amint létrejön egy kommunikációs csatorna, az A útválasztó azonnal Hello csomagot küld az A útválasztónak. Ez a csomag olyan információkat tartalmaz majd, hogy ez a router még nem „látott” senkit ezen a csatornán, mert először küld Hello üzenetet, valamint a saját azonosítóját, a hozzá kapcsolódó hálózat adatait és egyéb információkat, amelyeket tud megosztani a szomszéddal.
Miután megkapta ezt a csomagot, a B útválasztó ezt mondja: „Látom, hogy ezen a kommunikációs csatornán van potenciális jelölt OSPF szomszédnak”, és Init állapotba lép. A Hello csomag nem unicast vagy broadcast üzenet, hanem a 224.0.0.5 multicast OSPF IP-címre küldött multicast csomag. Vannak, akik azt kérdezik, hogy mi az alhálózati maszk a csoportos küldéshez. A multicastnak ugyanis nincs alhálózati maszkja, rádiójelként terjed, amit minden frekvenciájára hangolt eszköz hall. Ha például egy FM-rádiót szeretne hallgatni a 91,0-s frekvencián, akkor erre a frekvenciára kell hangolnia a rádiót.
Ugyanígy a B útválasztó úgy van beállítva, hogy üzeneteket fogadjon a 224.0.0.5 csoportos küldési címre. Ennek a csatornának a hallgatása közben fogadja az A Router által küldött Hello csomagot, és saját üzenettel válaszol.
Ebben az esetben szomszédság csak akkor állapítható meg, ha a B válasz megfelel a kritériumoknak. Az első feltétel az, hogy a Hello üzenetek küldésének gyakorisága és az erre az üzenetre adott válasz várakozási időköze (Dead Interval) azonos legyen mindkét útválasztónál. A holt intervallum általában több Hello időzítő értékkel egyenlő. Így ha az A router Hello Timerje 10 s, és a B router 30 s után küld neki üzenetet, míg a holt intervallum 20 s, akkor a szomszédosság nem történik meg.
A második feltétel az, hogy mindkét útválasztónak 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 a hálózati előtag hosszának egyezése. Ha az A router /24-es előtagot jelez, akkor a B-útválasztónak is /24-es hálózati előtaggal kell rendelkeznie. A következő videóban ezt nézzük meg részletesebben, egyelőre megjegyzem, hogy ez nem egy alhálózati maszk, itt a routerek fordított Wildcard maszkot használnak. És természetesen a csonkterület jelzőinek is meg kell egyezniük, ha az útválasztók ebben a zónában vannak.
A feltételek ellenőrzése után, ha megfelelnek, a B útválasztó elküldi a Hello csomagját az A útválasztónak. A üzenettel ellentétben a Router B arról számol be, hogy látta az A routert, és bemutatkozik.
Erre az üzenetre válaszul az A router ismét Hello üzenetet küld a B útválasztónak, amelyben megerősíti, hogy látta a B útválasztót is, a köztü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 egy nagyon fontos szakasza a szomszédság kialakításának. Ebben az esetben kétirányú 2-WAY kapcsolatot használunk, de mi történik, ha 4 routerből álló elosztott hálózattal rendelkezünk? Egy ilyen „megosztott” környezetben az egyik útválasztónak a kijelölt útválasztó DR szerepét kell játszania, a másodiknak pedig a biztonsági másolatként kijelölt útválasztó, BDR szerepét kell betöltenie.
Ezen eszközök mindegyike teljes kapcsolatot, vagy teljes szomszédos állapotot fog kialakítani, később megnézzük, mi ez, de ilyen típusú kapcsolat csak DR-el és BDR-vel jön létre, a két alsó D és B router továbbra is kommunikálnak egymással egy kétirányú kapcsolati séma "pont-pont" használatával.
Vagyis a DR és a BDR esetében minden útválasztó teljes szomszédsági kapcsolatot hoz létre, egymással pedig pont-pont kapcsolatot. Ez nagyon fontos, mert a szomszédos eszközök közötti kétirányú kapcsolat során minden Hello csomag paraméternek meg kell egyeznie. Nálunk minden egyezik, így a készülékek gond nélkül alkotnak egy szomszédságot.
Amint létrejön a kétirányú kommunikáció, az A útválasztó elküldi a B útválasztónak egy adatbázisleíró csomagot, vagy „adatbázisleírást”, és ExStart állapotba lép – a csere kezdete, vagy betöltésre vár. Az adatbázis-leíró egy könyv tartalomjegyzékéhez hasonló információ – ez mindennek a listája, ami az útválasztási adatbázisban található. Válaszul a B útválasztó elküldi az adatbázis leírását az A útválasztónak, és belép az Exchange csatorna kommunikációs állapotába. Ha Exchange állapotban az útválasztó azt észleli, hogy bizonyos információk hiányoznak az adatbázisából, akkor LOADING betöltési állapotba kerül, és megkezdi az LSR, LSU és LSA üzenetek cseréjét a szomszédjával.
Tehát az A útválasztó egy LSR-t küld a szomszédjának, aki LSU csomaggal válaszol, amelyre A router LSA üzenettel válaszol a B útválasztónak. Ez a csere annyiszor fog megtörténni, ahányszor az eszközök LSA üzenetet akarnak váltani. A LOADING állapot azt jelenti, hogy az LSA adatbázis teljes frissítése még nem történt meg. Az összes adat letöltése után mindkét eszköz TELJES szomszédsági állapotba lép.
Vegye figyelembe, hogy kétirányú kapcsolat esetén az eszközök egyszerűen szomszédsági állapotban vannak, és a teljes szomszédsági állapot csak a routerek, a DR és a BDR között lehetséges.Ez azt jelenti, hogy minden útválasztó értesíti a DR-t a hálózat változásairól, és az összes router tájékozódjon ezekről a változásokról DR
A DR és BDR kiválasztása fontos kérdés. Nézzük meg, hogyan választják ki a DR-t egy általános környezetben. Tegyük fel, hogy a sémánk három útválasztót és egy kapcsolót tartalmaz. Az OSPF-eszközök először összehasonlítják a Hello üzenetek prioritását, majd az útválasztó azonosítóját.
A legmagasabb prioritású eszköz DR lesz Ha két eszköz prioritása egybeesik, akkor a legmagasabb router azonosítóval rendelkező eszköz kerül kiválasztásra a kettő közül, és az lesz DR.
A második legmagasabb prioritású vagy a második legmagasabb Router ID-vel rendelkező eszköz lesz a tartalék dedikált BDR router. Ha a DR meghibásodik, azonnal lecseréli a BDR-re. Az elkezdi a DR szerepét, és a rendszer másikat választ. BDR
Remélem, hogy rájött a DR és a BDR kiválasztására, ha nem, akkor a következő videók egyikében visszatérek erre a kérdésre, és elmagyarázom a folyamatot.
Eddig megvizsgáltuk, mi az a Hello, az adatbázis-leíró, valamint az LSR, LSU és LSA üzenetek. Mielőtt rátérnénk a következő témára, beszéljünk egy kicsit az OSPF költségeiről.
A Ciscónál az útvonal költségét az alapértelmezés szerint 100 Mbit/s-ra beállított referenciasávszélesség és a csatorna költségének arányának képlete alapján számítják ki. Például soros porton keresztül eszközök csatlakoztatásakor a sebesség 1.544 Mbps, a költség pedig 64. 10 Mbps sebességű Ethernet kapcsolat esetén a költség 10, a FastEthernet kapcsolat költsége pedig a 100 Mbps sebesség 1 lesz.
Gigabit Ethernet használatakor 1000 Mb/s sebességgel rendelkezünk, de ebben az esetben a sebességet mindig 1-nek feltételezzük. Tehát, ha Gigabit Ethernet van a hálózaton, módosítania kell a Ref. alapértelmezett értékét. BW 1000-rel. Ebben az esetben a költség 1 lesz, és a teljes táblázat újraszámításra kerül úgy, hogy a költségértékek 10-szeresére nőnek. Miután kialakítottuk a szomszédságot és felépítettük az LSDB-t, folytatjuk az útválasztási tábla felépítését.
Miután megkapta az LSDB-t, minden útválasztó önállóan elkezdi létrehozni az útvonalak listáját az SPF algoritmus segítségével. Sémánkban az A útválasztó létrehoz egy ilyen táblázatot magának. Például kiszámítja az A-R1 útvonal költségét, és meghatározza, hogy ez 10. A diagram könnyebb megértése érdekében tegyük fel, hogy az A útválasztó határozza meg az optimális útvonalat a B útválasztóhoz. Az A-R1 kapcsolat költsége 10 , az A-R2 link 100, az A-R3 útvonal költsége pedig 11, azaz az A-R1(10) és az R1-R3(1) útvonal összege.
Ha az A router az R4 routerhez szeretne eljutni, akkor ezt akár az A-R1-R4 útvonalon, akár az A-R2-R4 útvonalon megteheti, és mindkét esetben az útvonalak költsége azonos lesz: 10+100 =100+10=110. Az A-R6 út 100+1= 101 lesz, ami már jobb. Ezután megvizsgáljuk az R5 útválasztóhoz vezető utat az A-R1-R3-R5 útvonalon, amelynek költsége 10+1+100 = 111.
Az R7 útválasztóhoz vezető út két útvonalon fektethető le: A-R1-R4-R7 vagy A-R2-R6-R7. Az első ára 210, a másodiké 201, ami azt jelenti, hogy 201-et kell választania. Tehát a B útválasztó eléréséhez az A router 4 útvonalat használhat.
Az A-R1-R3-R5-B útvonal ára 121. Az A-R1-R4-R7-B útvonal 220. Az A-R2-R4-R7-B útvonal 210, az A-R2- Az R6-R7- B költsége 211. Ez alapján az A router kiválasztja a legalacsonyabb költségű útvonalat, amely 121, és elhelyezi az útválasztási táblázatban. Ez egy nagyon leegyszerűsített diagram az SPF algoritmus működéséről. Valójában a táblázat nemcsak azon routerek megnevezését tartalmazza, amelyeken keresztül az optimális útvonal fut, hanem az őket összekötő portok megnevezését és minden egyéb szükséges információt is.
Nézzünk egy másik témát, amely az útválasztási zónákra vonatkozik. Jellemzően egy vállalat OSPF eszközeinek beállításakor mindegyik egy közös zónában található.
Mi történik, ha az R3 útválasztóhoz csatlakoztatott eszköz hirtelen meghibásodik? Az R3 router azonnal elkezd üzenetet küldeni az R5 és R1 útválasztóknak, hogy az eszközzel rendelkező csatorna már nem működik, és az összes útválasztó frissíteni kezd erről az eseményről.
Ha 100 útválasztója van, mindegyik frissíti a kapcsolat állapotára vonatkozó információkat, mert ugyanabban a közös zónában vannak. Ugyanez történik, ha az egyik szomszédos útválasztó meghibásodik - a zónában lévő összes eszköz cseréli az LSA-frissítéseket. Az ilyen üzenetek cseréje után maga a hálózati topológia megváltozik. Ha ez megtörténik, az SPF újraszámolja az útválasztási táblákat a megváltozott feltételeknek megfelelően. Ez egy nagyon nagy folyamat, és ha egy zónában ezer eszköz van, akkor az útválasztók memóriaméretét kell szabályozni, hogy elegendő legyen az összes LSA és a hatalmas LSDB kapcsolatállapot-adatbázis tárolására. Amint változás történik a zóna valamely részén, az SPF algoritmus azonnal újraszámítja az útvonalakat. Alapértelmezés szerint az LSA 30 percenként frissül. Ez a folyamat nem megy végbe minden eszközön egyszerre, de mindenesetre az egyes routerek 30 percenként frissítéseket hajtanak végre. Minél több hálózati eszköz. Minél több memória és idő szükséges az LSDB frissítéséhez.
Ezt a problémát úgy lehet megoldani, hogy egy közös zónát több különálló zónára osztunk, azaz többzónás zónát használunk. Ehhez rendelkeznie kell az Ön által kezelt teljes hálózat tervével vagy diagramjával. A 0. TERÜLET az Ön fő területe. Ez az a hely, ahol létrejön a külső hálózathoz való csatlakozás, például az internethez való hozzáférés. Új zónák létrehozásakor be kell tartani a szabályt: minden zónának rendelkeznie kell egy ABR, Area Border Routerrel. Egy szélső útválasztónak van egy interfésze az egyik zónában, és egy második interfésze egy másik zónában. Például az R5 router interfésszel rendelkezik az 1. zónában és a 0. zónában. Mint mondtam, mindegyik zónának a nulladik zónához kell kapcsolódnia, vagyis rendelkeznie kell egy szélső útválasztóval, amelynek az egyik interfésze a 0. TERÜLETRE csatlakozik.
Tegyük fel, hogy az R6-R7 kapcsolat meghibásodott. Ebben az esetben az LSA frissítés csak az 1. TERÜLETEN keresztül terjed, és csak ezt a zónát érinti. A 2. és 0. zónában lévő eszközök nem is fognak tudni róla. Az R5 Edge router összefoglalja a zónájában zajló eseményeket, és összefoglaló információkat küld a hálózat állapotáról a 0. TERÜLET főzónába. Az egyik zónában lévő eszközöknek nem kell tudniuk minden LSA változást a többi zónán belül, mert az ABR útválasztó az összesített útvonalinformációt továbbítja egyik zónából a másikba.
Ha nem vagy teljesen tisztában a zónák fogalmával, többet megtudhat a következő leckékben, amikor az OSPF-útválasztás konfigurálásával foglalkozunk, és néhány példát tekintünk meg.
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, 30% kedvezmény a Habr felhasználóknak a belépő szintű szerverek egyedülálló analógjára, amelyet mi találtunk ki Önnek:
Dell R730xd kétszer olcsóbb? Csak itt
Forrás: will.com