Werking van het PIM-protocol

Het PIM-protocol is een set protocollen voor het verzenden van multicast in netwerken tussen routers. Buurrelaties worden opgebouwd op dezelfde manier als bij dynamische routeringsprotocollen. PIMv2 verzendt elke 30 seconden Hello-berichten naar het gereserveerde multicastadres 224.0.0.13 (All-PIM-Routers). Het bericht bevat Hold Timers — meestal gelijk aan 3,5 keer de Hello Timer, dat wil zeggen standaard 105 seconden.

PIM heeft twee hoofdwerkmodi — Dense en Sparse mode. Laten we beginnen met Dense mode.
Source-Based Distribution Trees.
De Dense-mode is geschikt voor situaties met veel cliënten in verschillende multicastgroepen. Wanneer een router multicastverkeer ontvangt, controleert hij eerst de RPF-regel. RPF — deze regel wordt gebruikt om de bron van de multicast te controleren met de unicast-routeringstabel. Het verkeer moet binnenkomen via de interface waar deze host staat volgens de unicast-routeringstabel. Dit mechanisme voorkomt het ontstaan van lussen bij het verzenden van multicast.

R3 leert uit het multicastbericht de bron van de multicast (Source IP) en controleert twee stromen van R1 en R2 volgens zijn unicast-routeringstabel. De stroom van de interface waarop de tabel wijst (R1 naar R3) wordt verder verzonden, terwijl de stroom van R2 wordt gedropt, aangezien het nodig is om pakketten via S0/1 naar de multicastbron te sturen.
Wat gebeurt er als u twee equivalente routes met dezelfde metriek heeft? In dit geval kiest de router op basis van de next-hop van deze routes. Degene met het hoogste IP-adres wint. Als u dit gedrag wilt wijzigen, kunt u ECMP gebruiken. Meer informatie here.
Na controle van de RPF-regel verzendt de router het multicastpakket naar al zijn PIM-buren, behalve degene van wie het pakket is ontvangen. De andere PIM-routers herhalen dit proces. De weg die het multicastpakket van de bron naar de eindontvangers heeft afgelegd, vormt een boom die een source-based distribution tree, shortest-path tree (SPT), source tree wordt genoemd. Drie verschillende namen, kies er een.
Hoe op te lossen dat sommige routers geen specifieke multicaststroom kunnen verwerken en er niemand is om deze te versturen, terwijl een hogere router deze wel blijft sturen. Hiervoor is het Prune-mechanisme bedacht.
Prune-bericht.
Bijvoorbeeld, R2 blijft R3 multicast sturen, hoewel R3 het volgens de RPF-regel afwijst. Waarom de bandbreedte belasten? R3 stuurt een PIM Prune Message en R2, bij ontvangst van dit bericht, verwijdert de interface S0/1 uit de lijst van uitgaande interfaces voor deze stroom, de lijst van interfaces waarover dit verkeer verzonden moet worden.

Hieronder staat een meer formele definitie van een PIM Prune-bericht:
Het PIM Prune-bericht wordt door de ene router naar een tweede router gestuurd om de tweede router te laten stoppen met het gebruik van de link waarop de Prune wordt ontvangen voor een specifieke (S,G) SPT.

Na ontvangst van het Prune-bericht stelt R2 de Prune-timer in op 3 minuten. Na drie minuten begint hij weer verkeer te verzenden, totdat hij een nieuw Prune-bericht ontvangt. Dit is in PIMv1.
In PIMv2 is een State Refresh-timer toegevoegd (standaard 60 seconden). Zodra er een Prune-bericht is verzonden met R3, wordt deze timer op R3 gestart. Na het verstrijken van deze timer zal R3 een State Refresh-bericht verzenden, dat de 3-minuten Prune-timer op R2 voor deze groep reset.
Redenen voor het verzenden van een Prune-bericht:

• Wanneer een multicastpakket niet voldoet aan de RPF-controle.
• Wanneer er geen lokaal aangesloten cliënten zijn die de multicastgroep (IGMP Join) hebben aangevraagd en er geen PIM-buren zijn om multicastverkeer (Non-prune Interface) naar te verzenden.

Graft Message.
Stel je voor dat R3 geen verkeer van R2 wilde, een Prune heeft verzonden en multicast van R1 ontving. Maar plotseling viel de verbinding tussen R1-R3 en R3 zat zonder multicast. Je kunt 3 minuten wachten tot de Prune-timer van R2 verstrijkt. 3 minuten wachten is lang, om te voorkomen dat je moet wachten, moet je een bericht verzenden dat deze interface S0/1 op R2 onmiddellijk uit de pruned-status haalt. Een dergelijk bericht is het Graft-bericht. Na ontvangst van het Graft-bericht zal R2 als antwoord Graft-ACK versturen.
Prune Override.

Laten we naar dit schema kijken. R1 zendt multicast uit naar een segment met twee routers. R3 ontvangt en zendt verkeer, R2 ontvangt, maar heeft niemand om het verkeer uit te zenden. Hij stuurt een Prune-bericht naar R1 in dit segment. R1 moet Fa0/0 uit de lijst verwijderen en stoppen met uitzenden in dit segment, maar wat gebeurt er met R3? R3 bevindt zich in hetzelfde segment, heeft ook dit Prune-bericht ontvangen en begrijpt de ernst van de situatie. Voordat R1 stopt met uitzenden, stelt hij een timer in van 3 seconden en stopt hij met uitzenden na 3 seconden. 3 seconden — dat is precies de tijd die R3 heeft om zijn multicast niet te verliezen. Daarom stuurt R3 zo snel mogelijk een Pim Join-bericht voor deze groep en denkt R1 al niet meer na over stoppen met uitzenden. Meer over de Join-berichten hieronder.
Assert-bericht.

Stel je de volgende situatie voor: twee routers zenden tegelijkertijd uit naar één netwerk. Beide ontvangen dezelfde stroom van de bron en zenden deze uit naar één netwerk via de interface e0. Daarom moeten ze bepalen wie de enige uitzendende router voor dit netwerk zal zijn. Hiervoor worden Assert-berichten gebruikt. Wanneer R2 en R3 duplicatie van multicastverkeer detecteren, dat wil zeggen dat de multicast die ze zelf uitzenden, ook op R2 en R3 binnenkomt, begrijpen de routers dat er iets aan de hand is. In dit geval sturen de routers Assert-berichten, waarin de Administrative Distance en de metriek van de route waarmee ze de multicastbron bereiken — 10.1.1.10 — zijn opgenomen. De winnaar wordt als volgt bepaald:

1. Degene met de laagste AD.
2. Als de AD gelijk zijn, dan degene met de laagste metriek.
3. Als er ook hier sprake is van gelijkheid, dan degene met het hoogste IP-adres in het netwerk waar ze deze multicast uitzenden.

De winnaar van deze stemming wordt de Designated Router. Voor de keuze van de DR worden ook Pim Hello-berichten gebruikt. Aan het begin van het artikel werd het PIM Hello-bericht getoond, waar het DR-veld kan worden opgemerkt. Degene met het hoogste IP-adres op deze link wint.
Nuttige tabel:

MROUTE-tafel.
Na de eerste bespreking van de werking van het PIM-protocol, moeten we begrijpen hoe we met de multicast-routeringstabel moeten werken. In de mroute-tabel wordt informatie opgeslagen over welke stromen door klanten zijn opgevraagd en welke stromen van multicastservers worden verzonden.
Bijvoorbeeld, wanneer een IGMP Membership Report of PIM Join op een bepaalde interface wordt ontvangen, wordt er een record van het type ( *, G ) aan de routeringstabel toegevoegd:

Deze vermelding betekent dat er een verzoek voor verkeer is ontvangen van het adres 238.38.38.38. De vlag DC betekent dat multicast zal werken in Dense mode en C betekent dat de ontvanger rechtstreeks is verbonden met de router, dat wil zeggen dat de router een IGMP Membership Report heeft ontvangen, en PIM Join.
Als er een record van het type (S,G) is, betekent dit dat we een multicaststroom hebben:

In het veld S — 192.168.1.11, hebben we het IP-adres van de multicastbron, dat zal worden gecontroleerd door de RPF-regel. Bij problemen moet eerst de unicast-tabel worden gecontroleerd op de route naar de bron. In het veld Incoming Interface wordt de interface aangegeven waarop de multicast binnenkomt. In de unicast-routeringstabel moet de route naar de bron verwijzen naar de interface die hier is aangegeven. In Outgoing Interface wordt aangegeven waar de multicast naartoe zal worden doorgestuurd. Als deze leeg is, betekent dit dat er geen verzoeken voor dit verkeer naar de router zijn gekomen. Meer gedetailleerde informatie over alle vlaggen is te vinden hier.
PIM Sparse-mode.
De Sparse-mode strategie is het tegenovergestelde van de Dense-mode. Wanneer Sparse-mode multicastverkeer ontvangt, zal het verkeer alleen worden verzonden via die interfaces waar aanvragen voor deze stroom zijn gedaan, bijvoorbeeld Pim Join of IGMP Report berichten met een verzoek voor dit verkeer.
Vergelijkbare elementen van SM en DM:

• Buurrelaties worden gebouwd op dezelfde manier als in PIM DM.
• De RPF-regel werkt.
• De keuze voor DR is vergelijkbaar.
• De Prune Overrides mechanisme en Assert-berichten zijn vergelijkbaar.

Om te controleren wie, waar en welk multicastverkeer nodig heeft in het netwerk, is er een gezamenlijk informatiecentrum nodig. Dit centrum is ons Rendezvous Point (RP). Iedereen die multicastverkeer wil of die multicastverkeer van de bron begint te ontvangen, stuurt het naar de RP.
Wanneer de RP multicastverkeer ontvangt, zal deze het verzenden naar de routers die eerder om dit verkeer hebben gevraagd.

Stel je een topologie voor waarin RP R3 is. Zodra R1 verkeer van S1 ontvangt, verpakt het dit multicastpakket in een unicast PIM Register bericht en stuurt het naar de RP. Hoe weet het wie de RP is? In dit geval is deze statisch ingesteld, en we zullen later spreken over de dynamische instelling van RP.

ip pim rp-address 3.3.3.3

RP kijkt of er informatie is van iemand die deze traffic zou willen ontvangen. Laten we aannemen van niet. Dan zal RP een Register-Stop bericht naar R1 sturen, wat betekent dat niemand de multicast nodig heeft, registratie is geweigerd. R1 zal geen multicast verzenden. Maar de host die de multicast verzendt, zal deze blijven sturen, zodat R1 na het ontvangen van de Register-Stop een Register-Suppression timer van 60 seconden zal starten. Vijf seconden voor het verstrijken van deze timer, zal R1 een leeg Registerbericht met de Null-Register bit (dus zonder verpakte multicast-pakket) naar RP sturen. RP zal vervolgens als volgt handelen:

• Als er geen ontvangers waren, zal hij reageren met een Register-Stop bericht.
• Als er ontvangers zijn verschenen, zal hij er niet op reageren. R1, zonder een weigering van zijn registratie binnen 5 seconden te ontvangen, zal zich verheugen en een Registerbericht met een verpakte multicast naar RP sturen.

Hoe de multicast RP bereikt, is duidelijk; nu proberen we de vraag te beantwoorden hoe RP de traffic naar de ontvangers brengt. Hier moeten we een nieuw begrip introduceren: root-path tree (RPT). RPT is een boom met de wortel in RP, die in de richting van de ontvangers groeit en zich vertakt bij elke PIM-SM router. RP creëert deze door PIM Join berichten te ontvangen en voegt een nieuwe tak aan de boom toe. Dit doet elke onderliggende router ook. De algemene regel is als volgt:

• Wanneer een PIM-SM router een PIM Join bericht ontvangt op een interface, behalve de interface waarachter RP zich bevindt, voegt hij een nieuwe tak aan de boom toe.
• Een tak wordt ook toegevoegd wanneer een PIM-SM router een IGMP Membership Report ontvangt van een direct aangesloten host.

Stel dat we een multicast-cliënt hebben op router R5 voor groep 228.8.8.8. Zodra R5 een IGMP Membership Report van de host ontvangt, stuurt R5 een PIM Join richting RP en voegt hij de interface die naar de host kijkt toe aan de boom. Vervolgens ontvangt R4 de PIM Join van R5, voegt de interface Gi0/1 toe aan de boom en stuurt een PIM Join richting RP. Ten slotte ontvangt RP (R3) de PIM Join en voegt hij Gi0/0 toe aan de boom. Zo wordt een ontvanger van de multicast geregistreerd. We bouwen een boom met de wortel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Daarna wordt er een PIM Join naar R1 verzonden en begint R1 multicastverkeer te verzenden. Het is belangrijk op te merken dat als de host verkeer heeft aangevraagd voordat de multicast-uitzending begon, RP geen PIM Join zal verzenden en in het geheel niets naar R1 zal verzenden.
Als de host stopt met het willen ontvangen van multicast terwijl het nog wordt verzonden, zodra RP een PIM Prune op de interface Gi0/0 ontvangt, zal het onmiddellijk een PIM Register-Stop rechtstreeks naar R1 verzenden en vervolgens ook een PIM Prune-bericht via interface Gi0/1. PIM Register-stop wordt unicast verzonden naar het adres waar PIM Register vandaan kwam.
Zoals we eerder hebben gezegd, zodra de router een PIM Join naar een andere, bijvoorbeeld R5 op R4, verzendt, wordt er een vermelding toegevoegd op R4:

En een timer wordt gestart, die R5 verplicht om voortdurend PIM Join-berichten te verzenden, anders zal R4 R5 uit de outgoing list verwijderen. R5 zal elke 60 seconden PIM Join-berichten verzenden.
Shortest-Path Tree-overgang.
We zullen een interface tussen R1 en R5 toevoegen en kijken hoe het verkeer vloeit bij deze topologie.

Stel dat het verkeer werd verzonden en ontvangen volgens het oude schema R1-R2-R3-R4-R5 en dat we nu de interface tussen R1 en R5 hebben aangesloten en geconfigureerd.
Ten eerste zal de unicast-routingstabel op R5 worden opnieuw opgebouwd en nu is het netwerk 192.168.1.0/24 bereikbaar via de interface R5 Gi0/2. Nu, wanneer R5 multicast op interface Gi0/1 ontvangt, begrijpt het dat de RPF-regel niet wordt voldaan en dat multicast logischerwijs via Gi0/2 zou moeten worden ontvangen. Het moet zich loskoppelen van RPT en een kortere boom opbouwen, die de Shortest-Path Tree (SPT) wordt genoemd. Hiervoor verzendt het via Gi0/2 een PIM Join naar R1 en R1 begint ook multicast via Gi0/2 te verzenden. Nu moet R5 zich afmelden van RPT, zodat het geen twee kopieën ontvangt. Hiervoor verzendt het een Prune-bericht met het IP-adres van de bron en voegt een speciale bit toe — RPT-bit. Dit betekent dat ik geen verkeer wil ontvangen, want ik heb hier een betere boom. RP verzendt ook PIM Prune-berichten naar R1, maar verzendt geen Register-Stop-bericht. Een ander kenmerk: R5 zal nu voortdurend PIM Prune naar RP verzenden, omdat R1 elke minuut PIM Register naar RP blijft verzenden. RP zal R5, zolang er geen nieuwe belangstellenden zijn voor dit verkeer, met een weigering antwoorden. R5 meldt RP dat het blijft multicast ontvangen via SPT.
Dynamische zoektocht naar RP.
Auto-RP.
Deze technologie is eigendom van Cisco en is niet bijzonder populair, maar bestaat nog steeds. De werking van Auto-RP bestaat uit twee hoofdsecties:
1) RP stuurt RP-Announce berichten naar een gereserveerd adres — 224.0.1.39, waarbij het zichzelf als RP aankondigt, hetzij voor allemaal, hetzij voor specifieke groepen. Dit bericht wordt elke minuut verzonden.
2) Er is een RP mapping agent nodig, die RP-Discovery berichten verstuurt met de vermelding voor welke groepen welke RP moet worden beluisterd. Uit dit bericht zullen gewone PIM routers hun RP bepalen. De Mapping Agent kan zowel de RP-router zelf zijn als een aparte PIM-router. RP-Discovery wordt verzonden naar adres 224.0.1.40 met een timer van één minuut.
Laten we het proces nader bekijken:
Laten we R3 instellen als RP:

ip pim send-rp-announce loopback 0 scope 10

R2 als mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

En op alle andere zullen we RP via Auto-RP verwachten:

ip pim autorp listener

Zodra we R3 hebben ingesteld, begint hij RP-Announce te verzenden:

En R2 zal na de instelling als mapping agent beginnen te wachten op RP-Announce berichten. Pas als hij minstens één RP vindt, begint hij RP-Discovery te verzenden:

Dus zodra gewone routers (PIM RP Listener) dit bericht ontvangen, weten ze waar ze RP moeten zoeken.
Een van de belangrijkste problemen van Auto-RP is dat om RP-Announce en RP-Discovery berichten te ontvangen, er PIM Join naar de adressen 224.0.1.39-40 moet worden verzonden, en om dat te doen, moet men weten waar de RP zich bevindt. Het klassieke probleem van de kip en het ei. Om dit probleem op te lossen, werd de PIM Sparse-Dense-Mode uitgevonden. Als een router de RP niet kent, werkt deze in Dense-mode, en als hij de RP kent, in Sparse-mode. Wanneer op de interfaces van gewone routers PIM Sparse-mode en het commando ip pim autorp listener zijn ingesteld, zal de router alleen in Dense-mode werken voor de multicast van het Auto-RP protocol (224.0.1.39-40).
BootStrap Router (BSR).
Deze functie werkt vergelijkbaar met Auto-RP. Elke RP stuurt een bericht naar de mapping agent, die de mapping informatie verzamelt en deze vervolgens aan alle andere routers vertelt. We beschrijven het proces op dezelfde manier als Auto-RP:
1) Zodra we R3 instellen als kandidaat om RP te zijn, met het commando:

ip pim rp-candidate loopback 0

Zal R3 niets doen, om speciale berichten te beginnen verzenden, moet hij eerst de mapping agent vinden. Laten we dus overstappen naar de tweede stap.
2) We stellen R2 in als mapping agent:

ip pim bsr-candidate loopback 0

R2 begint PIM Bootstrap berichten te verzenden, waarbij hij zichzelf als mapping agent aangeeft:

Dit bericht wordt verzonden naar het adres 224.0.0.13, dat door het PIM-protocol wordt gebruikt voor andere berichten. Het wordt in alle richtingen verzonden, waardoor het probleem van de kip en het ei, zoals bij Auto-RP, niet ontstaat.
3) Zodra de RP een bericht van de BSR-router ontvangt, zal hij onmiddellijk een unicastberichten naar het adres van de BSR-router sturen:

Vervolgens zal de BSR, na het ontvangen van informatie over de RP, deze multicast verzenden naar het adres 224.0.0.13, dat door alle PIM-routers wordt beluisterd. Daarom is er geen analoog commando ip pim autorp listener voor gewone routers in de BSR.
Anycast RP met Multicast Source Discovery Protocol (MSDP).
Auto-RP en BSR stellen ons in staat om de belasting op de RP als volgt te verdelen: Elke multicastgroep heeft slechts één actieve RP. Het is niet mogelijk om de belasting voor een enkele multicastgroep over meerdere RP's te verdelen. MSDP doet dit door RP-routers hetzelfde ip-adres met een subnetmasker van 255.255.255.255 te geven. MSDP vergaart informatie via een van de methoden: statisch, Auto-RP of BSR.

In de afbeelding zien we een Auto-RP-configuratie met MSDP. Beide RP's zijn ingesteld met het ip-adres 172.16.1.1/32 op de Loopback 1 interface en worden voor alle groepen gebruikt. Bij RP-Announce vertellen beide routers over zichzelf, verwijzend naar dit adres. De Auto-RP mapping agent, die deze informatie ontvangt, verspreidt RP-Discovery over de RP met het adres 172.16.1.1/32. Voor het netwerk 172.16.1.1/32 vertellen we de routers via IGP, en respectievelijk. Zo vragen of registreren PIM-routers streams van de RP die als next-hop is aangegeven in de route naar het netwerk 172.16.1.1/32. Het MSDP-protocol is ontworpen voor de RP om berichten uit te wisselen over informatie over multicast.
Laten we een dergelijke topologie overwegen:

Switch6 zendt verkeer uit naar het adres 238.38.38.38 en alleen RP-R1 weet hiervan. Switch7 en Switch8 hebben deze groep aangevraagd. Routers R5 en R4 zullen PIM Join naar R1 en R3 verzenden, respectievelijk. Waarom? De route naar 13.13.13.13 zal voor R5 verwijzen naar R1 op basis van IGP-metriek, net als bij R4.
RP-R1 is bekend met de stream en zal deze in de richting van R5 uitzenden, terwijl R4 er niets over weet, omdat R1 dit gewoon niet zal verzenden. Daarom is MSDP nodig. We configureren het op R1 en R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 op R1

ip msdp peer 1.1.1.1 connect-source Loopback3 op R3

Ze zullen een sessie tussen elkaar opzetten en, wanneer ze een stream ontvangen, zullen ze hierover rapporteren aan hun buur-RP.
Wanneer RP-R1 een stroom van Switch6 ontvangt, zal het onmiddellijk een unicast MSDP Source-Active bericht sturen, waarin informatie zoals (S, G) — informatie over de bron en bestemming van de multicast — zal worden opgenomen. Nu RP-R3 weet dat er een bron zoals Switch6 bestaat, zal het bij ontvangst van een verzoek van R4 voor deze stroom een PIM Join in de richting van Switch6 verzenden, overeenkomstig de routeringstabel. Daarom zal R1, bij ontvangst van deze PIM Join, verkeer in de richting van RP-R3 beginnen te verzenden.
MSDP werkt op basis van TCP, RP's sturen elkaar keepalive-berichten om de levensvatbaarheid te controleren. De timer is 60 seconden.
De functie van het splitsen van MSDP-peers in verschillende domeinen blijft onduidelijk, omdat in de keepalive- en SA-berichten geen toewijzing aan een bepaald domein wordt aangegeven. Ook werd in deze topologie een configuratie getest waarbij verschillende domeinen werden opgegeven — er was geen verschil in werking.
Als iemand verduidelijking kan bieden, lees ik graag de opmerkingen.

Bron: habr.com