A PIM protocol is a set of protocols for multicast transmission over a network between routers. Neighbor relationships are built similarly to dynamic routing protocols. PIMv2 sends Hello messages every 30 seconds to the reserved multicast address 224.0.0.13 (All-PIM-Routers). The message contains Hold Timers — usually set to 3.5 * Hello Timer, which defaults to 105 seconds.
PIM uses two main operating modes — Dense and Sparse mode. Let's start with Dense mode.
Source-Based Distribution Trees.
The dense-mode is advisable to use in cases with a large number of clients from various multicast groups. When a router receives multicast traffic, it first checks it against the RPF rule. RPF — this rule is used to verify the multicast source against the unicast routing table. The traffic must come in on the interface that corresponds to the host in the unicast routing table. This mechanism solves the problem of loop formation during multicast transmission.
R3 learns the source of the multicast from the multicast message (Source IP) and checks two streams from R1 and R2 against its unicast table. The stream from the interface indicated by the table (R1 to R3) will be forwarded, while the stream from R2 will be dropped, since packets must be sent via S0/1 to reach the multicast source.
What happens if you have two equivalent routes with the same metric? In this case, the router will choose based on the next-hop of these routes. The one with the higher IP address wins. If you need to change this behavior, you can use ECMP. More details .
After validating the RPF rule, the router sends the multicast packet to all its PIM neighbors, except for the one from whom it received the packet. Other PIM routers repeat this process. The path that the multicast packet travels from source to final recipients forms a tree called the source-based distribution tree, shortest-path tree (SPT), or source tree. Three different names, choose any.
How to address the issue where certain routers do not need a particular multicast stream and there is no one to send it to, while a higher-level router is sending it? The Prune mechanism was invented for this.
Prune Message.
Például az R2 továbbra is multicastot küld R3-nak, bár R3 az RPF szabály szerint eltávolítja azt. Miért terheljük a kapcsolatot? Az R3 PIM Prune üzenetet küld, és az R2, miután megkapta ezt az üzenetet, eltávolítja az S0/1 interfészt az adott forgalom kimeneti interfészlistájáról.
Az alábbiakban egy formálisabb meghatározás a PIM Prune üzenetről:
A PIM Prune üzenetet az egyik router küldi el a második routernek, hogy arra ösztönözze, hogy távolítsa el a Prune-t fogadó linket egy adott (S,G) SPT-ből.
A Prune üzenet megérkezése után az R2 3 percre beállítja a Prune időzítőt. Három perc elteltével újra megkezdi a forgalom küldését, amíg nem kap újabb Prune üzenetet. Ez a PIMv1.
A PIMv2-ben hozzáadták az State Refresh időzítőt (alapértelmezett 60 másodperc). Amint Prune üzenetet küld az R3, elindul ez az időzítő az R3-on. Ennek az időzítőnek a lejárta után az R3 State Refresh üzenetet küld, amely visszaállítja az R2 Prune Tárcsázási időzítőt a csoport számára.
A Prune üzenet küldésének okai:
- Amikor a multicast csomag nem felelt meg az RPF ellenőrzésnek.
- Amikor nincsenek helyben csatlakozott ügyfelek, akik multicast csoportot kértek (IGMP Join), és nincsenek PIM szomszédok, akiknek multicast forgalmat lehetne küldeni (Non-prune Interface).
Graft üzenet.
Tegyük fel, hogy az R3 nem akarta az R2-től a forgalmat, Prune-t küldött, és multicastot kapott az R1-től. De hirtelen megszűnt a kapcsolat az R1 és az R3 között, és az R3 multicast nélkül maradt. Három percet várni hosszú, ezért szükséges egy üzenet küldése, amely azonnal megszünteti az S0/1 interfészt az R2 pruned állapotából. Ezt az üzenetet Graft üzenetnek nevezzük. A Graft üzenet megérkezése után az R2 válaszul Graft-ACK-et küld.
Prune Override.
Nézzük meg ezt a sémát. R1 multicastot sugároz egy szegmensben két routerrel. R3 fogadja és sugározza a forgalmat, R2 fogadja, de nincs akinek sugároznia. Ő elküldi a Prune üzenetet R1-nek ebbe a szegmensbe. R1-nek el kell távolítania a Fa0/0-at a listájából, és meg kell szüntetnie a sugárzást ebben a szegmensben, de mi lesz R3-mal? R3 ugyanabban a szegmensben van, ő is megkapta ezt a Prune üzenetet és megértette a helyzet tragikusságát. Mielőtt R1 leállítja 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 — ennyi idő áll rendelkezésre R3-nak, hogy ne veszítse el a multicastját. Ezért R3 a lehető leghamarabb elküldi a Pim Join üzenetet a csoport számára, így R1 már nem gondolkodik a sugárzás leállításán. A Join üzenetekről lent.
Assert üzenet.
Képzeljünk el egy ilyen helyzetet: egy hálózatba egyszerre két router sugároz. Mindkettő ugyanazt a folyamot kapja a forrástól, és mindketten sugározzák azt egy hálózaton keresztül az e0 interfészen. Ezért meg kell határozniuk, ki lesz az egyetlen sugárzó a hálózat számára. Ehhez Assert üzeneteket használnak. Amikor R2 és R3 észlelik a multicast forgalom duplikációját, azaz a multicast, amelyet maguk is sugároznak, a routerek megértik, hogy valami nem stimmel. Ilyen esetben a routerek Assert üzeneteket küldenek, amelyek tartalmazzák az Administrative Distance-t és az útvonal metrikáját, amellyel elérik a multicast forrást — 10.1.1.10. A győztest így határozzák meg:
- Akié a kisebb AD.
- Ha az AD-k egyenlőek, akkor akié a kisebb metrika.
- Ha itt is egyenlőség van, akkor akié a magasabb IP a hálózaton, amelyben ezt a multicastot sugározzák.
A vállalkozás győztese router Designated Router lesz. A DR kiválasztásához a Pim Hello üzeneteket is használják. A cikk elején bemutatott PIM Hello üzenetben látható a DR mező. Az nyer, akinek a legmagasabb IP-címe van ezen a linken.
Hasznos táblázat:
MROUTE Táblázat.
A PIM protokoll működésének kezdeti áttekintése után meg kell ismernünk, hogyan kell kezelni a multicast útválasztási táblát. Az mroute táblázatban tárolódik az információ arról, hogy milyen folyamokat kértek az ügyfelek, és milyen folyamok érkeznek a multicast szerverekről.
Például az IGMP Membership Report vagy a PIM Join érkezésekor egy interfészen, egy ( *, G ) típusú bejegyzés kerül hozzáadásra az útválasztási táblához:
Ez a bejegyzés azt jelenti, hogy forgalmi kérés érkezett a 238.38.38.38 címről. A DC zászló azt jelzi, hogy a multicasting sűrű módban működik, és a C azt jelzi, hogy a fogadó 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 (S,G) típusú bejegyzés, akkor van multicasting forgalmunk:
Az S mezőben — 192.168.1.11 szerepel, ez a multicasting forrás IP címe, amelyet az RPF szabály ellenőrizni fog. Problémák esetén először az unicast táblázatot kell ellenőrizni a forráshoz vezető útvonalért. Az Incoming Interface mező megadja azt az interfészt, amelyre a multicasting érkezik. Az unicast útválasztási táblázatban a forráshoz vezető útvonalnak hivatkoznia kell a itt megadott interfészre. Az Outgoing Interface mezőben megadódik, hová irányítják a multicastingot. Ha üres, akkor az útválasztóhoz nem érkeztek kérdések a forgalomra. Részletesebb információt az összes zászlóról találhat. .
PIM Sparse-mode.
A Sparse-mode stratégia ellentétes a Dense-mode-dal. Amikor a Sparse-mode multicasting forgalmat kap, azt csak azokhoz az interfészekhez fogja küldeni, ahol kérdések érkeztek a folyamba, például Pim Join vagy IGMP Jelentés üzenetek, kérve ezt a forgalmat.
Hasonló elemek az SM és DM között:
- 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ának folyamata hasonló.
- A Prune Overrides mechanizmus és az Assert üzenetek hasonlóak.
A multicasting forgalom ellenőrzéséhez, hogy ki, hol és milyen multicasting forgalomra van szüksége a hálózatban, szükséges egy központi információs központ. Ez a központ nálunk a Rendezvous Point (RP). Mindenki, aki szeretne valamilyen multicasting forgalmat, vagy aki elkezdett multicasting forgalmat kapni a forrástól, azt eljuttatja az RP-hez.
Amikor az RP megkapja a multicasting forgalmat, elküldi azt azoknak az útválasztóknak, akik ezt a forgalmat korábban kértek.
Képzeljünk el egy olyan topológiát, ahol az RP az R3. Amint az R1 megkapja a forgalmat az S1-től, a multicasting csomagot encapsulálja egy unicast PIM Register üzenetbe, és elküldi az RP-nek. Honnan tudja, ki az RP? Ebben az esetben statikusan van beállítva, a dinamikus RP konfigurálásról később beszélünk.
ip pim rp-address 3.3.3.3
A RP megvizsgálja, hogy volt-e információ valakitől, aki szeretette volna megkapni ezt a forgalmat. Tegyük fel, hogy nem volt. Ekkor a RP elküldi az R1-nek a PIM Register-Stop üzenetet, ami azt jelenti, hogy senkinek sincs szüksége erre a multicastra, a regisztrációt elutasítják. Az R1 nem küld multicastot. De a multicast forráshost továbbra is küldeni fogja, így az R1 a Register-Stop üzenet megérkezése után elindít egy 60 másodperces Register-Suppression időzítőt. 5 másodperccel a időzítő lejárta előtt az R1 üres Register üzenetet küld a Null-Register bit-tel (tehát anélkül, hogy encapsulated multicast csomagot küldene) RP felé. A RP pedig a következőképpen reagál:
- Ha a címzettek sehol sincsenek, akkor válaszol a Register-Stop üzenettel.
- Ha megjelentek a címzettek, akkor nem válaszol rá. Az R1, ha 5 másodpercen belül nem kap elutasítást a regisztrációjára, örömmel elküldi a Register üzenetet encapsulated multicasttal RP felé.
Most, hogy tisztáztuk, hogyan jut el a multicast a RP-hez, próbáljuk megválaszolni a kérdést, hogy a RP hogyan juttatja el a forgalmat a címzettekhez. Itt egy új fogalmat kell bevezetni — root-path tree (RPT). Az RPT egy fa, amelynek gyökere a RP, és a címzettek felé növekszik, minden PIM-SM routeren elágazva. A RP létrehozza ezt, amikor PIM Join üzeneteket kap, és új ágat ad hozzá a fához. Így tesz minden alsóbb szintű router is. Az általános szabály a következőképpen néz ki:
- Amikor egy PIM-SM router PIM Join üzenetet kap egy bármely interfészen, kivéve azt az interfészt, amely mögött a RP rejtőzik, új ágat ad hozzá a fához.
- Egy új ág akkor is hozzáadódik, amikor a PIM-SM router IGMP Membership Report-ot kap közvetlenül csatlakoztatott hosttól.
Tegyük fel, hogy van egy multicast kliens az R5 routeren a 228.8.8.8 csoportban. Amint az R5 megkapja az IGMP Membership Report-ot a hosttól, az R5 PIM Join üzenetet küld RP irányába, és hozzáadja a fát az interfészén, amely a host felé néz. Ezután az R4 megkapja az R5-től a PIM Join üzenetet, hozzáadja a Gi0/1 interfészt a fához, és PIM Join üzenetet küld RP irányába. Végül a RP (R3) megkapja a PIM Join üzenetet, és hozzáadja a Gi0/0-t a fához. Így megvalósul a multicast címzett regisztrálása. Fát építünk, amelynek gyökere R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Ezt követően egy PIM Join üzenet lesz küldve az R1-nek, és az R1 elkezdi küldeni a multicast forgalmat. Fontos megjegyezni, hogy ha a host kérte a forgalmat, mielőtt a multicast sugárzás megkezdődött, akkor az RP nem küld PIM Join üzenetet, és egyáltalán nem küld semmit az R1 felé.
Ha esetleg a multicast küldése alatt a host megáll a fogadni vágyástól, amint az RP megkapja a PIM Prune üzenetet a Gi0/0 interfészen, azonnal elküldi a PIM Register-Stop üzenetet közvetlenül az R1-nek, majd a PIM Prune üzenetet a Gi0/1 interfészen. A PIM Register-stop üzenetet unicast formában küldik arra a címre, ahonnan a PIM Register érkezett.
Ahogyan korábban említettük, amint a router PIM Join üzenetet küld egy másik routernek, például az R5-nek az R4-en, R4-nek hozzáadódik egy bejegyzés:
És elindul egy időzítő, amelynek az R5-nek folyamatosan PIM Join üzeneteket kell küldenie, különben az R4 kizárja az outgoing listából. Az R5 minden 60 másodpercben PIM Join üzeneteket fog küldeni.
Legrövidebb Útvonal Fa Átkapcsolás.
Hozzáadunk egy interfészt az R1 és az R5 között, és megnézzük, hogyan fog áramlani a forgalom ezzel a topológiával.
Tegyük fel, hogy a forgalom a régi séma szerint folyt R1-R2-R3-R4-R5, és most csatlakoztattuk és beállítottuk az interfészt az R1 és az R5 között.
Első lépésként, az R5 unicast routing táblája átalakul, és most a 192.168.1.0/24 hálózat az R5 Gi0/2 interfészén érhető el. Most, amikor az R5 multicastot fogad a Gi0/1 interfészen, észleli, hogy az RPF szabály nem teljesül, és logikusabb lenne multicastot fogadni a Gi0/2-n. Le kell választania az RPT-ről és létrehoznia egy rövidebb fát, amit Legrövidebb Útvonal Fának (SPT) hívnak. Ehhez a Gi0/2-n keresztül PIM Join üzenetet küld az R1-nek, és az R1 elkezdi a multicastot küldeni a Gi0/2-n is. Az R5-nek le kell mondania az RPT-ről, hogy ne kapjon két példányt. Ehhez Prune üzenetet küld, megadva a forrás ip-címét, és beillesztve egy speciális bitet — RPT-bit. Ez azt jelenti, hogy nem kell nekem forgalmat küldeni, itt van egy jobb fáma. Az RP szintén PIM Prune üzenetet küld az R1 felé, de Register-Stop üzenetet nem küld. Egy másik sajátosság: az R5 most folyamatosan PIM Prune üzeneteket fog küldeni az RP-nek, mivel az R1 minden percben PIM Register üzenetet küld az RP-nek. Az RP addig válaszolni fog az elutasítással az R5-nek, amíg nem lesznek új érdeklődők a forgalom iránt. Az R5 értesíti az RP-t, hogy folytatja a multicast fogadását az SPT-n keresztül.
Dinamikus RP keresés.
Auto-RP.
Ez a technológia a Cisco tulajdonát képezi, és nem igazán népszerű, de még mindig létezik. Az Auto-RP működése két fő szakaszból áll:
1) Az RP RP-Announce üzeneteket küld egy fenntartott címre — 224.0.1.39, kihirdetve magát RP-nek, vagy mindenki, vagy bizonyos csoportok számára. Ezt az üzenetet minden percben elküldi.
2) Szükség van egy RP mapping agent-re, amely RP-Discovery üzeneteket küld, jelezve, hogy mely csoportokhoz mely RP-t kell figyelni. Ebből az üzenetből a hagyományos PIM routerek meg fogják határozni a saját RP-jüket. A Mapping Agent lehet maga az RP router, vagy bármilyen más PIM router. Az RP-Discovery üzenetet a 224.0.1.40 címre küldik, egyperces időzítővel.
Nézzük meg a folyamatot részletesebben:
Állítsuk be az R3-at RP-ként:
ip pim send-rp-announce loopback 0 scope 10
R2 mint mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
Mindenki más pedig várja az RP-t az Auto-RP-n keresztül:
ip pim autorp listener
Amint beállítjuk az R3-at, elkezdi küldeni az RP-Announce üzeneteket:
Az R2 pedig a mapping agent beállítása után elkezd várni az RP-Announce üzenetekre. Csak akkor, amikor talál legalább egy RP-t, elkezdi küldeni az RP-Discovery üzeneteket:
Így a hagyományos routerek (PIM RP Listener) amint megkapják ezt az üzenetet, tudni fogják, hol keressék az RP-t.
Az Auto-RP egyik fő problémája, hogy az RP-Announce és RP-Discovery üzenetek fogadásához PIM Join-t kell küldeni a 224.0.1.39-40 címekre, és ahhoz, hogy ezt megtegyük, tudnunk kell, hol található az RP. Klasszikus tojás-kibúvós probléma. E probléma megoldására a PIM Sparse-Dense-Mode módot találták ki. Ha a router nem tudja az RP-t, akkor Dense-mode-ban működik, ha tudja, akkor Sparse-mode-ban. Amikor a hagyományos routerek interfészein a PIM Sparse-mode van beállítva és az ip pim autorp listener parancs, akkor a router csak az Auto-RP protokoll multicastjára (224.0.1.39-40) Dense-mode-ban fog működni.
BootStrap Router (BSR).
Ez a funkció hasonlóan működik az Auto-RP-hez. Minden RP üzenetet küld a mapping agent-nek, aki összegyűjti a leképezési információkat, majd elmondja a többi routernek. Írjuk le a folyamatot hasonlóan az Auto-RP-hez:
1) Amint beállítjuk az R3-at jelölt RP-nek e parancs segítségével:
ip pim rp-candidate loopback 0
Az R3 nem fog semmit tenni, hogy elkezdje küldeni a különleges üzeneteket, első lépésben meg kell találnia a mapping agent-et. Így lépünk a második lépésre.
2) Állítsuk be az R2-t mint mapping agent:
ip pim bsr-kandidált hurok 0
Az R2 elkezdi küldeni a PIM Bootstrap üzeneteket, amelyben magát mapping agent-ként jelöli meg:
Ez az üzenet a 224.0.0.13 címre kerül elküldésre, amit a PIM protokoll más üzeneteihez is használ. Mivel minden irányba elküldi őket, ezért nem merül fel a csirke és tojás problémája, mint az Auto-RP esetében.
3) Miután az RP megkapja az üzenetet a BSR routertől, azonnal unicast üzenetet küld a BSR router címére:
Ezután a BSR, miután információt kapott az RP-ről, multicastban továbbítja őket a 224.0.0.13 címre, amit minden PIM router figyel. Ezért a parancsnak ip pim autorp listener nincs analógja a BSR-ben a szokásos routereknél.
Anycast RP a Multicast Source Discovery Protocol-lal (MSDP).
Az Auto-RP és a BSR lehetővé teszi az RP terhelésének elosztását a következőképpen: Minden multicast csoportnak csak egy aktív RP-je van. Nem lehet terhelést elosztani egyetlen multicast csoport esetén több RP között. Az MSDP ezzel az eljárással oszt ki az RP routereknek azonos IP-címet 255.255.255.255 maszk mellett. Az MSDP az információt az alábbi módszerek egyikével szerzi meg: statikus, Auto-RP vagy BSR.
A képen az Auto-RP konfiguráció látható MSDP-vel. Mindkét RP 172.16.1.1/32 IP-címmel van beállítva a Loopback 1 interfészen, és ez minden csoporthoz használatos. A RP-Announce során mindkét router tájékoztatja magáról, hivatkozva erre a címre. Az Auto-RP mapping agent, miután információt kap, RP-Discovery üzenetet küld a 172.16.1.1/32 című RP-hez. A 172.16.1.1/32 hálózatról a routereknek az IGP-n keresztül beszélünk, és ennek megfelelően. Így a PIM routerek kérnek vagy regisztrálnak folyamokat attól az RP-től, amelyik a 172.16.1.1/32 hálózat útvonalának next-hop-ja. Magának az MSDP protokollnak az a célja, hogy az RP-k között információt cseréljen a multicast-ról.
Vizsgáljuk meg ezt a topológiát:
A Switch6 forgalmat bocsát ki a 238.38.38.38 címre, és erről eddig csak az RP-R1 tud. A Switch7 és Switch8 pedig kérik ezt a csoportot. Az R5 és R4 routerek PIM Join üzenetet küldenek R1 és R3 felé, a megfelelően. Miért? Az R5-nek a 13.13.13.13 címhez vezető útvonal az R1-re mutat IGP metrikával, éppúgy, mint az R4 esetében.
Az RP-R1 tud a folyamról, és elkezdi azt R5 irányába sugározni, de az R4 nem tud róla, mivel az R1 csak úgy nem fogja elküldeni. Ezért szükség van az MSDP-re. Az R1-en és R5-ön állítsuk be:
ip msdp partner 3.3.3.3 connect-source Loopback1 az R1-en
ip msdp partner 1.1.1.1 connect-source Loopback3 az R3-on
Felemelik a kapcsolatot egymás között, és bármilyen folyam megérkezésekor értesítik RP szomszédjukat.
Amikor az RP-R1 megkapja az áramlást a Switch6-tól, azonnal unicast MSDP Source-Active üzenetet küld, amely tartalmazni fogja az (S, G) információt - a multicast forrására és céljára vonatkozó információt. Most, hogy az RP-R3 tudja, hogy ilyen forrás létezik, mint a Switch6, amikor az R4 kérdést küld neki ezt az áramlást, az PIM Join üzenetet fog küldeni a Switch6 irányába a routing táblázat alapján. Ennek megfelelően az R1, miután megkapta ezt a PIM Join üzenetet, elkezdi a forgalmat az RP-R3 felé irányítani.
Az MSDP TCP-n működik, az RP-k keepalive üzeneteket küldenek egymásnak a működőképesség ellenőrzésére. Az időzítő 60 másodperc.
Nem világos, hogy az MSDP peer-ek különböző domain-ekbe való szétválasztásának funkciója hogyan működik, mivel a Keepalive és SA üzenetekben nincs meghatározva, hogy melyik domainhez tartoznak. Ezen a topológián belül különböző domain-ek megadásával is tesztelték a konfigurációt - a működésben nem volt különbség.
Ha valaki tudna tisztázni, örömmel olvasnám a hozzászólásokban.
Forrás: habr.com
