News & Blog

OSPF szomszédsági kapcsolat

News & Blog

OSPF szomszédsági kapcsolat kiépítése

Az OSPF forgalomirányító protokoll egyik legfontosabb lépése, amikor a szomszédos forgalomirányítók szomszédsági viszonyt létesítenek egymással, amennyiben szükséges, elvégzik a DR/BDR választást, majd kicserélik a kapcsolatállapot információikat. Nézzük meg, hogyan is működik ez a folyamat.

Mindenekelőtt azokat a feltételeket kell tisztázni, mikor is alakulhat ki két forgalomirányító között OSPF szomszédsági viszony: (Itt csak a legfontosabb feltételeket említjük, tehát például a vak területek jelzőiről nem esik szó.)

  • Az összekapcsolódó interfészeiknek azonos alhálózati maszkkal, és azonos alhálózati azonosítóval kell rendelkezniük.
  • A Hello és a Dead időzítőiket azonos értékre kell beállítani.
  • Amennyiben hitelesítés van konfigurálva a két forgalomirányító között, annak sikeresen kell végződnie.

Induljunk ki az alábbi hálózatból. Mindegyik forgalomirányító 2-2 LAN-nal rendelkezik, melyek közül az egyiket loopback interfésszel szimulálunk. A két forgalomirányító OSPF Hello üzeneteket váltva egymással különböző köztes állapotokon keresztül érik el a szomszédsági viszonyt.

A forgalomirányítók OSPF üzenetek (csomagok) segítségével kommunikálnak egymással. Érdemes megjegyezni, hogy az OSPF 5 különböző típusú üzenetet  különböztet meg, melyek a következők:

  • Helló üzenet (Hello) – 1-es típusú
  • Adatbázis leíró üzenet (Database description, DBD) – 2-es típusú
  • Kapcsolatállapot kérés üzenet (Database request) – 3-as típusú
  • Kapcsolatállapot frissítés üzenet (Database update) – 4-es típusú
  • Kapcsolatállapot nyugtázás üzenet (Database acknowledgment) – 5-ös típusú

A szomszédsági kapcsolatot a Hello üzenetek segítségével építik fel különböző állapotokon keresztül áthaladva.Az OSPF összesen 7 féle állapotot különböztet meg, melyek a következők:

  • Down
  • Init (NBMA, pl. Frame Relay hálózatokban ehelyett az Attempt állapotot használja, amikor a szomszédokat nem dinamikusan találja meg, hanem statikusan mi konfiguráljuk.)
  • Two way
  • Exstart
  • Exchange
  • Loading
  • Full

Induláskor mind a két forgalomirányító DOWN állapotból indul. Ez az állapot jelzi, hogy még semmiféle üzenetet nem váltottak egymással. A Down állapotban a forgalomirányító meghatározza az OSPF azonosítóját (RID), meghatározza a network parancsokból, mely interfészeken kell majd az OSPF üzeneteket kiküldeni, illetve összegyűjti azokat az információkat, amelyek a Hello üzenetek felépítéséhez kell.

A szomszédsági viszony kialakításának első lépése, hogy az egyik forgalomirányító (legyen most ez az R1) egy Hello üzenetet küld a 224.0.0.5 csoportos címre egy adott linkjén. Azért küldi csoportos címre, mert még egyetlen szomszédot sem ismer. A 224.0.0.5 címre minden olyan forgalomirányító figyel, amelyen elindították egy OSPF folyamatot. Ezzel egyidőben R1 Init állapotba lép át. Az Init állapot azt jelzi, hogy a forgalomirányító küldött egy Hello üzenetet, és most vár a válaszra. Ebben a Hello üzenetben számos adat van beágyazva, többek között a következők (a fejléc tartalmát most nem részletezzük):

  • a forgalomirányító azonosítója (RID)
  • a Hello és a Dead intervallum értéke (innen tudja a másik, ha ezek nem egyeznek a sajátjával)
  • a terület azonosítója
  • a forgalomirányító adott interfészének OSPF prioritása (ezt a DR/BDR választásban használják)
  • a kijelölt (DR) és a tartalék kijelölt (BDR) forgalomirányítók azonosítója (az első Hello üzenetekben ezek értelemszerűen még nem ismertek)
  • az eddigi szomszédok listája (azoknak a szomszédos forgalomirányítóknak az azonosítói, akiktől kapott és elfogadott Hello üzenetet, az első Hello üzenetben ez a lista még üres)

Jelen topológiában R1 azonosítója a 10.0.0.1, míg R2-é a 10.0.0.2. (Az RID értéke ugye elsődlegesen egy a router-id paranccsal konfigurált érték, ha ez nincsen, akkor a legmagasabb IP című loopback interfész IP címe, míg ha ez sincsen, akkor a legmagasabb IP című fizikai interfész címe. Jelen esetben ez a loopback címéből van meghatározva.)

R2 fogadja ezt a Hello üzenetet, (örömmel veszi tudomásul, hogy a szomszédosság feltételének megfelel R1), és válaszul (szintén a 224.0.0.5 címre, de bizonyos esetekben küldheti R1 unicast címére is) visszaküld egy Hello üzenetet, melyben már a saját adatai mellett az is szerepel, hogy van egy szomszédja (R1 a 11.0.0.1 azonosítóval), akitől Hello üzenetet kapott és elfogadott. Ezzel egyidőben R2 DOWN állapotból INIT állapotba lép át. R1 fogadja ezt a Hello üzenetet, és elhelyezni R2 azonosítóját a szomszédsági táblájában, és saját magát TWO WAY (kétutas) állapotba helyezi. TWO WAY állapotba tehát akkor kerül egy forgalomirányító, ha a szomszédja Hello üzenetében felfedezi a saját maga azonosítóját, vagyis ez a Hello már válasz a saját Hello üzenetére. R1 ezután egy egyedi (unicast) üzenetben küld R2-nek egy Hello-t, melyben a szomszédok listájában már szerepel R2 azonosítója, így R2 is (felismerve a saját azonosítóját az üzenetben) saját magát TWO WAY állapotba helyezi. (Azért nem csoportos üzenetben küldi a R1 ezt a Hello-t, hogy R2 a lehető leghamarabb TWO WAY állapotba kerüljön.)

A folyamatot az alábbi ábrán lehet csomagszinten nyomon követni. Jól látható, ahogyan az egyes forgalomirányítók elfogadják egymást szomszédaiknak. Vegyük észre, hogy a Hello üzenetekben a DR és BDR forgalomirányítók még nem kerülnek kijelölésre, hiszen azok megválasztása csak ezután történik.

Érdekességképpen meg kell említeni, hogy INIT-ből TWO WAY állapotba nem csak egy Hello üzenet tud átbillenteni egy forgalomirányítót, hanem egy DBD csomag is. Ez főleg soros vonal feletti pont-pont kapcsolat esetén fordul elő.

 

DR/BDR (kijelölt és tartalék kijelölt) forgalomirányító választás

Többes hozzáférésű hálózatok esetén (mint az Ethernet), a kapcsolatállapot információk kicserélése csak akkor indulhat meg két szomszédos forgalomirányító között, ha lefolytatják a DR/BDR választást. Fontos tudni, hogy az OSPF irányítási területen nem egyetlen DR és egyetlen BDR lesz megválasztva, hanem minden többes hozzáférésű (szórásos) szegmensben történik egy-egy választás. Ennek a folyamatnak az az értelme, hogy nem minden forgalomirányítónak kell minden más forgalomirányítóval kapcsolatállapot információt cserélni, hanem mindegyik a DR-nek fogja elküldeni azokat, és a DR osztja meg aztán valamennyit a többi forgalomirányítóval. Így nem kell számolni akkora forgalommal az információcsere során. Ha a DR kiesik, akkor a BDR veszi át a szerepét. A DR/BDR választás csak az OSPF folyamat elindulásakor (gyakorlatilag amikor egyszerre felkapcsoljuk a hálózatban a forgalomirányítókat) egyszer fog megtörténni. Ha egy forgalomirányító később csatlakozik a hálózathoz (vagy akár egy interfészét később kapcsoljuk fel), akkor nem fut le még egyszer a választás. Aki az elején nincs jelen, az már nem szólhat bele a választás folyamatába. A következőkben csak a DR választásról beszélünk, a BDR a második helyezett lesz.

A DR választás az OSPF prioritáson alapul, egyenlő prioritás esetén viszont az RID dönt. Itt is a magasabb érték győz. OSPF prioritást interfészenként állíthatunk, így a DR választást minden többes hozzáférésű (gyakorlatilag Ethernet) szegmensen külön-külön befolyásolhatjuk.

Az OSPF a DR/BDR választást is a Hello üzenetekkel vezényli le. Mind R1, mind R2 egy-egy Hello üzenetben elküldik egymásnak (és a szegmens többi forgalomirányítójának), hogy kit tartanak  DR-nek és BDR-nek. Ha valamelyik jobbat tud (magasabb RID-jűt), akkor a többi megtanulja tőle. Jelen esetben erről nincsen szó, R1 és R2 is R2-t tartja DR-nek és R1-et BDR-nek.

Kapcsolatállapot információk hirdetése, cseréje, kapcsolatállapot adatbázis felépítése

Felépültek a szomszédsági kapcsolatok, megválasztották a kijelölt és a tartalék kijelölt forgalomirányítókat, nincsen más hátra, mint a kapcsolatállapot információk hirdetése, a kapcsolatállapot adatbázis felépítése. Ez a folyamat szintén a DBD csomagok küldésével kezdődik. Ne feledjük, a cél az, hogy minden forgalomirányító (legalábbis egy területen belül) ugyanazzal a kapcsolatállapot információkkal rendelkezzen, vagyis ugyanazt a topológiát lássák.

Mit írnak le ezek a DBD csomagok? A DBD csomagokat a kapcsolatállapot adatbázis kivonataként kell értelmeznünk. Nem az egyes kapcsolatok állapotát írják le, hanem azt, hogy az adott forgalomirányító milyen kapcsolatokról tud, illetve milyen friss ez az információ az adatbázisban. Egy ilyen DBD csomagot amikor megkap egy másik forgalomirányító, akkor össze tudja vetni a saját adatbázisával, és amennyiben azt látja, hogy a küldő forgalomirányító valami olyat tud, amit ő nem (ez lehet ismeretlen információ, vagy éppen valamilyen frissebb információ), akkor azt le tudja attól kérdezni.

A kapcsolatállapot információk cseréjét valamelyik forgalomirányítónak kezdeményezni kell. De melyiknek? Páronként a forgalomirányítók kijelölnek maguk közül egy master és egy slave forgalomirányítót. Értelemszerűen a master kezdeményezi a cseré. Nem lepődünk meg azon, hogy mindig a magasabb azonosítójú (RID) forgalomirányító lesz a master. (Vigyázzunk arra, hogy a DR és a master szerep nem egyenértékű. A DR egy sokkal általánosabb, magasabb szintű szerep. Ha egy szegmensben van például 5 forgalomirányító, akkor közülük egyetlen DR lesz kijelölve. Viszont master/slave viszonyba páronként kerülnek a forgalomirányítók, pontosan a kapcsolatot létesítő interfészeik).

Ez a master/slave választást az OSPF az exstart állapotában hajtja végre pár  adatbázis leíró (DBD) üzenetet váltva. A DBD üzenetekben három bittel jelöli az OSPF, éppen hol tart a folyamatban. Az első DBD üzeneteket az I (Init) bit jelzi, az M (More) bit jelzi, hogy lesznek még DBD üzenetek, és a számunkra most leglényegesebb MS (Master/Slave) bitet állítják a forgalomirányítók aszerint, hogy ki lesz a master. Kövessük végig az ábrát:

Először R1 üzeni R2-nek egy DBD csomagban (36-os), hogy szeretne master lenni, ehhez az MS (Master/Slave) bitet állítja 1-re. Az I (Init) bittel jelzi, hogy ez az első DBD csomagja, az M (More) bittel azt, hogy lesz még következő is. R2 szintén ugyanezt válaszolja R1-nek (I=1, M=1, MS=1) a 38-as csomaggal. R1 tudomásul veszi, hogy R2-nek nagyobb az RID-ja, így neki van joga a master szerepet betölteni, ezt a 39-es sorszámú DBD csomaggal jelzi. (Az I bit nincsen beállítva, hiszen nem az első DBD csomag, az M bit igen, hiszen küld később még DBD csomagokat az adatbázis szinkronizációjához, és az MS sincsen beállítva, hiszen már tudja, belőle nem lesz master.) Vegyük észre, a master/slave választás nem csoportcímmel történik, hiszen a forgalomirányítók páronként végzik el egymás unicast címét használva.

A Master/Slave viszony megválasztása mellett a forgalomirányítók megállapodnak egy sorszámozásban is, mellyel elérik, hogy mindig a legfrissebb kapcsolatállapotot információkat cserélik ki. A csomagokból láthatjuk, hogy mindkét forgalomirányító kezdeményez egy sorszámot (R1: 1288, R2: 2232), és végül a Masetr (R2) sorszámát fogják használni. (Látható, R1 a 39-es csomagban már ezt küldi vissza.)

Miután megválasztották a master forgalomirányítót, a forgalomirányítók Exchange állapotba kerülnek, amikor is DBD csomagokkal meghatározzák, hogy mennyi és milyen kapcsolatállapot információt cseréljenek ki. A kapcsolatállapot információ hirdetés másik elnevezése az LSA (Link State Advertisement). Ezeket az LSA-kat gyűjtik össze a forgalomirányítók a kapcsolatállapot adatbázisukban, az LADB-ben (Link State Advertisement Database).

A forgalomirányítók, tehát a fogadott DBD csomagokból meghatározzák (összevetik a saját LADB-jükkel), hogy mely LSA-kravan szükségük, és ezeket lekérik a DBD-t küldő forgalomirányítótól. A kéréseket a Database Request üzenetekben küldik el, a válaszokat a Database Update üzenetekben kapják meg, melyeket a Database Acknowledgment üzenetekkel nyugtáznak. Ezeknek az OSPF üzeneteknek a forgalmazásakor a forgalomirányítók Loading állapotban vannak. Amennyiben azt tapasztaljuk, hogy a forgalomirányítók beragadnak az exstart/exchange állapotok valamelyikébe, akkor joggal gyanakodhatunk arra, hogy a két interfészen nem azonos az MTU beállítása.

A szükséges LSA-k cseréje után, amikor is a két forgalomirányító kapcsolatállapot adatbázisa megegyezik, a forgalomirányítók Full állapotba váltanak. A Full állapotban egy konvergált hálózatban viszonylag eseménytelenül zajlik az idő. A forgalomirányítók a Hello időzítőjüknek megfelelő időnként (szórásos hálózatban 10 másodpercenként) kiküldenek egy-egy Hello üzenetet. A szomszéd Hello üzeneteire maximum a Dead időzítőjükben megadott ideig várnak (ez a Hello időzítő értékének 4-szerese), utána elveszettnek jelentik ezt a kapcsolatot. Ha nem változnak a kapcsolataik állapota, akkor is alapértelmezetten 30 percenként újra hirdetik az LSA-kat róluk.

Ezzel véget is ér a kapcsolatállapot adatbázis felépítése. A forgalomirányító ebből az adatbázisból a Dijkstra algoritmus segítségével épít fel egy terület alapú topológia fát (ez az SPF fa), ennek a fának a gyökerében elhelyezi saját magát, majd az összköltségek alapján minden más hálózatba meghatározza a legjobb útvonalat (egyenlő költségek esetén útvonalakat), melyeket aztán elhelyez az irányítótáblájában.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük