Hogyan működik a PIM protokoll

A PIM-protokoll protokollok halmaza a routerek közötti hálózatban történő csoportos küldés továbbítására. A szomszédsági kapcsolatok ugyanúgy épülnek fel, mint a dinamikus útválasztási protokollok esetében. A PIMv2 30 másodpercenként küld Hello üzeneteket a lefoglalt 224.0.0.13 (All-PIM-Router) csoportos küldési címre. Az üzenet Hold időzítőket tartalmaz – általában 3.5* Hello Timer, azaz alapértelmezés szerint 105 másodperc.

A PIM két fő üzemmódot használ - sűrű és ritka módot. Kezdjük a sűrű móddal.
Forrásalapú eloszlási fák.
A sűrű módú módot akkor célszerű használni, ha nagyszámú, különböző multicast csoporthoz tartozó kliens van. Amikor egy útválasztó multicast forgalmat fogad, először ellenőrzi az RPF-szabályt. RPF – ez a szabály a multicast forrásának ellenőrzésére szolgál egy unicast útválasztó táblával. Szükséges, hogy a forgalom arra az interfészre érkezzen, amely mögött ez a gazdagép el van rejtve az unicast útválasztási tábla verziója szerint. Ez a mechanizmus megoldja a multicast átvitel során fellépő hurok problémáját.

Az R3 felismeri a multicast forrást (Source IP) a csoportos üzenetből, és ellenőrzi az R1 és R2 két folyamát az unicast táblázata segítségével. A tábla által mutatott interfészről (R1-től R3-ig) érkező stream tovább fog kerülni, az R2-ről pedig eldobjuk, mivel a multicast forráshoz való eljutáshoz S0/1-en keresztül csomagokat kell küldeni.
A kérdés az, hogy mi történik, ha két egyenértékű útvonala van ugyanazzal a mérőszámmal? Ebben az esetben a router ezek közül az útvonalak közül választja ki a következő ugrást. Akinek magasabb az IP címe, az nyer. Ha módosítania kell ezen a viselkedésen, használhatja az ECMP-t. További részletek itt.
Az RPF-szabály ellenőrzése után az útválasztó csoportos küldésű csomagot küld az összes PIM-szomszédnak, kivéve azt, akitől a csomagot kapta. Más PIM útválasztók megismétlik ezt a folyamatot. Az útvonal, amelyet a csoportos küldési csomag a forrástól a végső címzettig megtett, egy forrásalapú terjesztési fának, legrövidebb úti fának (SPT) és forrásfának nevezett fát alkot. Három különböző név, válasszon egyet.
Hogyan lehet megoldani azt a problémát, hogy egyes routerek nem adtak fel valamilyen multicast streamet, és nincs kinek küldeni, de az upstream router küldi neki. Erre találták ki a Prune mechanizmust.
Metszés Üzenet.
Például az R2 továbbra is multicastot küld R3-nak, bár az R3 az RPF-szabály szerint eldobja azt. Miért töltse be a csatornát? Az R3 PIM Prune üzenetet küld, az R2 pedig, miután megkapta ezt az üzenetet, eltávolítja az S0/1 interfészt a kimenő interfészek listájáról a folyamathoz, azon interfészek listájából, amelyekről ezt a forgalmat el kell küldeni.

A következő a PIM Prune üzenet formálisabb meghatározása:
A PIM Prune üzenetet az egyik útválasztó elküldi egy második útválasztónak, hogy a második útválasztó eltávolítsa azt a hivatkozást, amelyen a szilva szilva fogad egy adott (S,G) SPT-től.

Miután megkapta a Metszés üzenetet, az R2 3 percre állítja a Metszés időzítőt. Három perc elteltével újra elkezdi küldeni a forgalmat, amíg nem kap egy újabb Metszés üzenetet. Ez a PIMv1-ben van.
És a PIMv2-ben egy állapotfrissítési időzítő került hozzáadásra (alapértelmezés szerint 60 másodperc). Amint egy metszésüzenetet küld az R3, ez az időzítő elindul az R3-on. Az időzítő lejártakor az R3 állapotfrissítési üzenetet küld, amely visszaállítja a 3 perces aszalt szilva időzítőt az R2-n ehhez a csoporthoz.
A szilvás üzenet küldésének okai:

• Ha egy csoportos küldési csomag meghiúsítja az RPF-ellenőrzést.
• Ha nincsenek helyileg csatlakoztatott kliensek, amelyek multicast csoportot kértek (IGMP Join), és nincsenek PIM-szomszédok, akiknek csoportos adatforgalmat lehetne küldeni (Non-prune Interface).

Üzenet átültetése.
Képzeljük el, hogy az R3 nem akart forgalmat R2-től, elküldte Prune-t és multicastot kapott R1-től. De hirtelen az R1-R3 közötti csatorna leesett, és R3 multicast nélkül maradt. Várhat 3 percet, amíg az R2 aszalt szilva időzítője lejár. 3 perc hosszú várakozás, hogy ne kelljen várni, egy üzenetet kell küldeni, ami azonnal kihozza ezt az S0/1 interfészt az R2-be a metszett állapotból. Ez az üzenet graft üzenet lesz. A graft üzenet fogadása után R2 graft-ACK-vel válaszol.
Szilva felülbírálása.

Nézzük ezt a diagramot. Az R1 csoportos küldést sugároz egy két útválasztóval rendelkező szegmensre. R3 fogadja és sugározza a forgalmat, R2 fogadja, de nincs kinek sugároznia a forgalmat. Üzenetet küld az R1-nek ebben a szegmensben. Az R1-nek el kell távolítania a Fa0/0-t a listáról, és le kell állítania a sugárzást ebben a szegmensben, de mi lesz az R3-mal? És R3 ugyanabban a szegmensben van, szintén megkapta ezt az üzenetet Prune-tól, és megértette a helyzet tragédiáját. Mielőtt az R1 leállítaná a sugárzást, 3 másodperces időzítőt állít be, és 3 másodperc múlva leállítja a sugárzást. 3 másodperc – pontosan ennyi ideje van R3-nak, hogy ne veszítse el a multicastját. Ezért R3 a lehető leghamarabb Pim Join üzenetet küld ennek a csoportnak, és R1 többé nem gondol a sugárzás leállítására. A csatlakozási üzenetekről alább.
Üzenet megerősítése.

Képzeljük el ezt a helyzetet: két router sugároz egyszerre egy hálózatra. Ugyanazt a streamet kapják a forrástól, és mindketten ugyanarra a hálózatra sugározzák az e0 interfész mögött. Ezért meg kell határozniuk, hogy ki lesz ennek a hálózatnak az egyetlen műsorszolgáltatója. Ehhez az assert üzeneteket használják. Amikor az R2 és R3 a multicast forgalom megkettőzését észleli, azaz R2 és R3 olyan multicastot kap, amelyet maguk sugároznak, az útválasztók megértik, hogy itt valami nincs rendben. Ebben az esetben az útválasztók Assert üzeneteket küldenek, amelyek magukban foglalják az Adminisztratív távolságot és az útvonal metrikáját, amellyel a csoportos küldési forrást elérni – 10.1.1.10. A nyertest az alábbiak szerint határozzák meg:

1. Az alacsonyabb AD.
2. Ha az AD egyenlő, akkor kié az alacsonyabb mutató.
3. Ha itt egyenlőség van, akkor annak, akinek a magasabb IP-je van abban a hálózatban, amelyre ezt a multicastot sugározzák.

A szavazás nyertese a Kijelölt Router lesz. A Pim Hello-t a DR-ek kiválasztására is használják. A cikk elején megjelent a PIM Hello üzenet, ott a DR mező látható. Az nyer, amelyik a legmagasabb IP-címmel rendelkezik ezen a linken.
Hasznos jel:

MROUTE táblázat.
A PIM protokoll működésének kezdeti áttekintése után meg kell értenünk, hogyan kell dolgozni egy multicast útválasztó táblával. Az mroute tábla információkat tárol arról, hogy mely adatfolyamokat kérték le az ügyfelektől, és mely adatfolyamok áramlanak a multicast szerverektől.
Például, amikor egy IGMP tagsági jelentés vagy PIM csatlakozás érkezik valamelyik felületre, egy ( *, G ) típusú rekord kerül az útválasztási táblába:

Ez a bejegyzés azt jelenti, hogy forgalmi kérés érkezett a 238.38.38.38 címmel. A DC jelző azt jelenti, hogy a multicast sűrű módban fog működni, a C pedig azt, hogy a címzett közvetlenül csatlakozik az útválasztóhoz, vagyis az útválasztó megkapta az IGMP tagsági jelentést és a PIM csatlakozást.
Ha van egy (S,G) típusú rekord, az azt jelenti, hogy van egy multicast adatfolyamunk:

Az S mezőben - 192.168.1.11 - regisztráltuk a multicast forrás IP-címét, ezt fogja ellenőrizni az RPF szabály. Ha problémák merülnek fel, először ellenőriznie kell az unicast táblában a forráshoz vezető útvonalat. A Bejövő interfész mezőben azt az interfészt jelöli, amelyre a csoportos küldés érkezik. Egy unicast útválasztási táblában a forráshoz vezető útvonalnak az itt megadott interfészre kell hivatkoznia. A kimenő interfész határozza meg, hová kerül átirányításra a csoportos küldés. Ha üres, akkor az útválasztó nem kapott erre a forgalomra vonatkozó kérést. Az összes zászlóról további információ található itt.
PIM ritka mód.
A Sparse-mode stratégiája a sűrű mód ellentéte. Amikor a Sparse-mode multicast forgalmat fogad, csak azokon az interfészeken keresztül küld forgalmat, ahol kérések érkeztek ehhez az áramláshoz, például Pim Join vagy IGMP Report üzenetek, amelyek ezt a forgalmat kérik.
Hasonló elemek az SM-hez és a DM-hez:

• A szomszédsági kapcsolatok ugyanúgy épülnek fel, mint a PIM DM-ben.
• Az RPF szabály működik.
• A DR kiválasztás hasonló.
• A Metszés felülbírálása és az Assert üzenetek mechanizmusa hasonló.

Egy közös információs központra van szükség annak szabályozására, hogy ki, hol és milyen multicast forgalomra van szükség a hálózaton. Központunk a Rendezvous Point (RP) lesz. Aki szeretne valamilyen multicast forgalmat, vagy valaki elkezdett multicast forgalmat kapni a forrástól, azt elküldi az RP-nek.
Amikor az RP multicast forgalmat fogad, elküldi azoknak az útválasztóknak, amelyek korábban kérték ezt a forgalmat.

Képzeljünk el egy topológiát, ahol az RP R3. Amint az R1 forgalmat fogad az S1-től, ezt a multicast csomagot egy unicast PIM Register üzenetbe foglalja, és elküldi az RP-nek. Honnan tudja, hogy ki az RP? Ebben az esetben statikusan van konfigurálva, a dinamikus RP konfigurációról később lesz szó.

ip pim rp-cím 3.3.3.3

Az RP megnézi – volt-e információ valakitől, aki szeretné megkapni ezt a forgalmat? Tegyük fel, hogy nem volt. Ekkor RP küld R1-nek egy PIM Register-Stop üzenetet, ami azt jelenti, hogy senkinek nincs szüksége erre a multicastra, a regisztráció megtagadva. Az R1 nem küld csoportos küldést. De a multicast forrás hoszt elküldi, így az R1, miután megkapta a Register-Stop jelzést, elindít egy 60 másodperces regisztráció-elnyomási időzítőt. 5 másodperccel az időzítő lejárta előtt az R1 üres regisztrációs üzenetet küld Null-Register bittel (vagyis tokozott multicast csomag nélkül) az RP felé. Az RP viszont így fog viselkedni:

• Ha nem voltak címzettek, akkor Regisztráció-leállítás üzenettel válaszol.
• Ha címzettek jelennek meg, arra semmilyen módon nem reagál. R1, miután 5 másodpercen belül nem kapta meg a regisztráció megtagadását, elégedett lesz, és egy beágyazott multicast-üzenetet küld az RP-nek.

Úgy tűnik, rájöttünk, hogyan éri el a multicast az RP-t, most próbáljuk meg megválaszolni azt a kérdést, hogy az RP hogyan juttatja el a forgalmat a címzettekhez. Itt be kell vezetni egy új koncepciót - a gyökérút-fát (RPT). Az RPT egy RP-ben gyökerező fa, amely a címzettek felé növekszik, és minden PIM-SM útválasztón elágazik. Az RP a PIM Join üzenetek fogadásával hozza létre, és új ágat ad a fához. És ez minden downstream router ezt teszi. Az általános szabály így néz ki:

• Amikor egy PIM-SM útválasztó PIM Join üzenetet kap bármely más interfészen, kivéve azon az interfészen, amely mögött az RP el van rejtve, új ágat ad hozzá a fához.
• Egy elágazás akkor is hozzáadódik, ha a PIM-SM útválasztó IGMP-tagsági jelentést kap egy közvetlenül csatlakoztatott gazdagéptől.

Képzeljük el, hogy van egy multicast kliensünk az R5 útválasztón a 228.8.8.8 csoporthoz. Amint az R5 megkapja az IGMP tagsági jelentést a gazdagéptől, az R5 PIM csatlakozást küld az RP irányába, és maga hozzáad egy interfészt a fához, amely a gazdagépet nézi. Ezután az R4 fogadja a PIM Joint az R5-től, hozzáadja a Gi0/1 interfészt a fához, és elküldi a PIM Joint az RP irányába. Végül az RP (R3) megkapja a PIM Join-t, és hozzáadja a Gi0/0-t a fához. Így a multicast címzett regisztrálva van. R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0 gyökérfát építünk.
Ezt követően egy PIM Join kerül elküldésre az R1-nek, és az R1 megkezdi a multicast forgalmat. Fontos megjegyezni, hogy ha a gazdagép forgalmat kért a csoportos adás megkezdése előtt, akkor az RP nem küld PIM Join-t, és egyáltalán nem küld semmit az R1-nek.
Ha a multicast küldése közben hirtelen a gazdagép nem akarja azt fogadni, amint az RP megkapja a PIM Prune-t a Gi0/0 interfészen, azonnal elküld egy PIM-regiszter-leállást közvetlenül az R1-nek, majd egy PIM Prune-t. üzenetet a Gi0/1 interfészen keresztül. A PIM-regiszter-leállítás unicast útján kerül elküldésre arra a címre, ahonnan a PIM-regiszter érkezett.
Ahogy korábban említettük, amint egy útválasztó PIM csatlakozást küld egy másiknak, például R5-ről R4-re, akkor a rendszer hozzáad egy rekordot az R4-hez:

És elindul egy időzítő, hogy az R5-nek folyamatosan vissza kell állítania ezt az időzítőt. Az R4 minden 5 PIM Join üzenetet elküld.
A legrövidebb útvonalú fa átváltása.
Hozzáadunk egy interfészt az R1 és R5 közé, és megnézzük, hogyan folyik a forgalom ezzel a topológiával.

Tegyük fel, hogy a forgalom küldése és fogadása a régi R1-R2-R3-R4-R5 séma szerint történt, és itt csatlakoztattuk és konfiguráltuk az R1 és R5 közötti interfészt.
Mindenekelőtt újra kell építeni az unicast útválasztó táblát az R5-ön, és most a 192.168.1.0/24 hálózatot az R5 Gi0/2 interfészen keresztül érjük el. Most az R5, amely a Gi0/1 interfészen fogadja a multicastot, megérti, hogy az RPF szabály nem teljesül, és logikusabb lenne Gi0/2-n fogadni a csoportos küldést. Le kell kapcsolódnia az RPT-ről, és létre kell hoznia egy rövidebb fát, úgynevezett Shortest-Path Tree (SPT). Ehhez elküldi a PIM Join-t R0-nek a Gi2/1-n keresztül, és R1 elkezdi a multicast küldését is Gi0/2-n keresztül. Az R5-nek most le kell iratkoznia az RPT-ről, hogy ne kapjon két példányt. Ehhez üzenetet küld a Prune-nak, amely jelzi a forrás IP-címét, és beilleszt egy speciális bitet - RPT-bit. Ez azt jelenti, hogy nem kell forgalmat küldenie, van itt egy jobb fa. Az RP PIM Prune üzeneteket is küld az R1-nek, de nem küld Regisztráció-leállítás üzenetet. Egy másik funkció: az R5 mostantól folyamatosan küldi a PIM Prune-t az RP-nek, mivel az R1 továbbra is percenként küldi a PIM-regisztert az RP-nek. Amíg nincs új ember, aki szeretné ezt a forgalmat, az RP visszautasítja. Az R5 értesíti az RP-t, hogy továbbra is fogadja a csoportos adást az SPT-n keresztül.
Dinamikus RP keresés.
Auto-RP.
Ez a technológia a Cisco szabadalma, és nem különösebben népszerű, de még mindig él. Az automatikus RP működése két fő szakaszból áll:
1) Az RP RP-Announce üzeneteket küld a fenntartott címre - 224.0.1.39, és mindenki vagy bizonyos csoportok számára RP-nek nyilvánítja magát. Ezt az üzenetet minden percben elküldik.
2) Szükség van egy RP-leképezési ügynökre, amely RP-Discovery üzeneteket küld, jelezve, hogy mely csoportokhoz melyik RP-t kell meghallgatni. Ebből az üzenetből áll, hogy a normál PIM-útválasztók maguk határozzák meg az RP-t. A Mapping Agent lehet maga az RP router vagy egy különálló PIM router. Az RP-Discovery a 224.0.1.40 címre kerül egy perces időzítővel.
Nézzük meg részletesebben a folyamatot:
Állítsuk be az R3-at RP-ként:

ip pim send-rp-announce loopback 0 hatókör 10

R2 mint leképezési ügynök:

ip pim send-rp-discovery loopback 0 hatókör 10

És az összes többinél RP-t várunk az Auto-RP-n keresztül:

ip pim autorp hallgató

Miután konfiguráltuk az R3-at, elkezdi az RP-Announce küldését:

Az R2 pedig a leképezési ügynök beállítása után elkezd várni az RP-Announce üzenetre. Csak ha talál legalább egy RP-t, akkor kezdi el az RP-Discovery küldését:

Így amint a hagyományos útválasztók (PIM RP Listener) megkapják ezt az üzenetet, tudni fogják, hol kell keresni az RP-t.
Az Auto-RP egyik fő problémája, hogy az RP-Announce és RP-Discovery üzenetek fogadásához el kell küldenie a PIM Join-t a 224.0.1.39-40-es címekre, a küldéshez pedig tudnia kell, hogy hova RP található. Klasszikus csirke és tojás probléma. Ennek a problémának a megoldására találták fel a PIM Sparse-Dense-Mode-t. Ha a router nem ismeri az RP-t, akkor sűrű módban működik, ha igen, akkor ritka módban. Ha a PIM Sparse-mode és az ip pim autorp listener parancs be van állítva a normál útválasztók interfészein, az útválasztó csak az Auto-RP protokollból (224.0.1.39-40) közvetlenül történő csoportos küldéshez fog működni sűrű módban.
BootStrap Router (BSR).
Ez a funkció az Auto-RP-hez hasonlóan működik. Minden RP üzenetet küld a leképezési ügynöknek, amely összegyűjti a leképezési információkat, majd tájékoztatja az összes többi útválasztót. Leírjuk a folyamatot az Auto-RP-hez hasonlóan:
1) Miután az R3-at RP jelöltként konfiguráltuk, a következő paranccsal:

ip pim rp-candidate loopback 0

Ekkor R3 nem tesz semmit; ahhoz, hogy speciális üzeneteket küldhessen, először meg kell találnia egy leképező ügynököt. Így továbblépünk a második lépésre.
2) Konfigurálja az R2-t leképezési ügynökként:

ip pim bsr-candidate loopback 0

Az R2 elkezd PIM Bootstrap üzeneteket küldeni, ahol leképezési ügynökként jelzi magát:

Ez az üzenet a 224.0.013 címre kerül elküldésre, amelyet a PIM protokoll a többi üzenetéhez is használ. Minden irányba elküldi őket, így nincs olyan tyúk-tojás probléma, mint az Auto-RP-ben.
3) Amint az RP üzenetet kap a BSR útválasztótól, azonnal egy unicast üzenetet küld a BSR útválasztó címére:

Ezt követően a BSR, miután megkapta az RP-kről szóló információkat, multicast útján elküldi azokat a 224.0.0.13 címre, amelyet az összes PIM útválasztó hallgat. Ezért a parancs analógja ip pim autorp hallgató normál útválasztókhoz, amelyek nem a BSR-ben találhatók.
Anycast RP Multicast Source Discovery Protocol-lal (MSDP).
Az Auto-RP és a BSR lehetővé teszi, hogy a következőképpen osszuk el az RP terhelését: Minden multicast csoportnak csak egy aktív RP-je van. Egy multicast csoport terhelése nem osztható el több RP-n. Az MSDP ezt úgy teszi meg, hogy az RP útválasztóknak ugyanazt az IP-címet adják ki, 255.255.255.255 maszkkal. Az MSDP a következő módszerek egyikével tanulja meg az információkat: statikus, Auto-RP vagy BSR.

A képen egy Auto-RP konfiguráció van MSDP-vel. Mindkét RP 172.16.1.1/32 IP-címmel van konfigurálva a Loopback 1 interfészen, és minden csoporthoz használatos. Az RP-Announce használatával mindkét útválasztó erre a címre hivatkozva jelenti be magát. Az Auto-RP leképezési ügynök, miután megkapta az információt, RP-Discovery-t küld az RP-ről a 172.16.1.1/32 címmel. A 172.16.1.1/32 hálózatról IGP-vel és ennek megfelelően tájékoztatjuk az útválasztókat. Így a PIM útválasztók folyamokat kérnek vagy regisztrálnak az RP-től, amely a következő ugrásként van megadva az útvonalon a 172.16.1.1/32 hálózat felé. Magát az MSDP protokollt arra tervezték, hogy maguk az RP-k üzeneteket cseréljenek a multicast információkról.
Tekintsük ezt a topológiát:

A Switch6 a forgalmat a 238.38.38.38 címre sugározza, és egyelőre csak az RP-R1 tud róla. Switch7 és Switch8 kérte ezt a csoportot. Az R5 és R4 útválasztó a PIM Join-t küldi az R1-nek, illetve az R3-nak. Miért? A 13.13.13.13-hoz vezető útvonal R5 esetében az R1-re fog hivatkozni az IGP metrikával, akárcsak az R4 esetében.
Az RP-R1 tud a streamről és elkezdi sugározni az R5 felé, de az R4 nem tud róla semmit, mivel az R1 nem egyszerűen elküldi. Ezért az MSDP-re van szükség. Az R1-en és az R5-ön konfiguráljuk:

ip msdp peer 3.3.3.3 connect-source Loopback1 az R1-en

ip msdp peer 1.1.1.1 connect-source Loopback3 az R3-en

Munkamenetet indítanak egymás között, és ha bármilyen áramlást kapnak, jelenteni fogják az RP szomszédjuknak.
Amint az RP-R1 streamet kap a Switch6-tól, azonnal küld egy unicast MSDP Source-Active üzenetet, amely olyan információkat tartalmaz, mint az (S, G) - információk a multicast forrásáról és célállomásáról. Most, hogy az RP-R3 tudja, hogy egy forrás, például a Switch6, amikor kérést kap az R4-től erre a folyamatra, elküldi a PIM Join-t a Switch6 felé, az útválasztási tábla irányításával. Következésképpen az R1, miután kapott egy ilyen PIM Join-t, forgalmat fog küldeni az RP-R3 felé.
Az MSDP TCP-n fut, az RP-k őrzőüzeneteket küldenek egymásnak az élőség ellenőrzésére. Az időzítő 60 másodperc.
Az MSDP társak különböző tartományokra való felosztásának funkciója továbbra is tisztázatlan, mivel a Keepalive és SA üzenetek nem jelzik a tagságot egyetlen tartományban sem. Ezenkívül ebben a topológiában különböző tartományokat jelző konfigurációt teszteltünk - nem volt különbség a teljesítményben.
Ha valaki tud pontosítani, szívesen elolvasom kommentben.

Forrás: will.com