Hoe het PIM-protocol werkt

Het PIM-protocol is een reeks protocollen voor het verzenden van multicast in een netwerk tussen routers. Buurtrelaties worden op dezelfde manier opgebouwd als in het geval van dynamische routeringsprotocollen. PIMv2 stuurt elke 30 seconden Hello-berichten naar het gereserveerde multicast-adres 224.0.0.13 (All-PIM-Routers). Het bericht bevat Hold Timers - meestal gelijk aan 3.5*Hello Timer, dat wil zeggen standaard 105 seconden.

PIM gebruikt twee hoofdmodi: Dense en Sparse-modus. Laten we beginnen met de Dense-modus.
Brongebaseerde distributiebomen.
Het is aan te raden om de Dense-mode-modus te gebruiken bij een groot aantal clients van verschillende multicast-groepen. Wanneer een router multicast-verkeer ontvangt, is het eerste wat hij doet het controleren op de RPF-regel. RPF - deze regel wordt gebruikt om de bron van een multicast te controleren met een unicast-routeringstabel. Het is noodzakelijk dat het verkeer aankomt op de interface waarachter deze host verborgen is volgens de versie van de unicast-routeringstabel. Dit mechanisme lost het probleem op van een lus die optreedt tijdens multicast-transmissie.

R3 herkent de multicast-bron (Bron-IP) uit het multicast-bericht en controleert de twee stromen van R1 en R2 met behulp van de unicast-tabel. De stream van de interface waarnaar de tabel verwijst (R1 tot R3) zal verder worden verzonden, en de stream van R2 zal worden verwijderd, omdat je, om bij de multicast-bron te komen, pakketten via S0/1 moet verzenden.
De vraag is: wat gebeurt er als je twee gelijkwaardige routes hebt met dezelfde metriek? In dit geval selecteert de router de volgende hop uit deze routes. Wie het hoogste IP-adres heeft, wint. Als u dit gedrag wilt wijzigen, kunt u ECMP gebruiken. Meer details hier.
Na controle van de RPF-regel stuurt de router een multicastpakket naar al zijn PIM-buren, behalve degene van wie het pakket is ontvangen. Andere PIM-routers herhalen dit proces. Het pad dat een multicastpakket heeft gevolgd van de bron naar de uiteindelijke ontvangers vormt een boom die op de bron gebaseerde distributieboom, de kortste padboom (SPT) en de bronboom wordt genoemd. Drie verschillende namen, kies er één.
Hoe het probleem op te lossen dat sommige routers een multicast-stream niet hebben opgegeven en er niemand is om deze naar toe te sturen, maar de upstream-router stuurt deze naar hem. Hiervoor is het Prune-mechanisme uitgevonden.
Snoei bericht.
R2 zal bijvoorbeeld doorgaan met het verzenden van een multicast naar R3, hoewel R3 deze, volgens de RPF-regel, laat vallen. Waarom het kanaal laden? R3 verzendt een PIM Prune-bericht en R2 zal bij ontvangst van dit bericht interface S0/1 verwijderen van de uitgaande interfacelijst voor deze stroom, de lijst met interfaces van waaruit dit verkeer moet worden verzonden.

Het volgende is een meer formele definitie van een PIM Prune-bericht:
Het PIM Prune-bericht wordt door de ene router naar een tweede router gestuurd om ervoor te zorgen dat de tweede router de link verwijdert waarop de Prune wordt ontvangen van een bepaalde (S,G) SPT.

Na ontvangst van het Prune-bericht stelt R2 de Prune-timer in op 3 minuten. Na drie minuten begint het opnieuw verkeer te verzenden totdat het opnieuw een Prune-bericht ontvangt. Dit bevindt zich in PIMv1.
En in PIMv2 is een State Refresh-timer toegevoegd (standaard 60 seconden). Zodra er vanuit R3 een Prune-bericht is verzonden, wordt deze timer op R3 gestart. Na het verstrijken van deze timer verzendt R3 een statusvernieuwingsbericht, waardoor de 3 minuten durende snoeitimer op R2 voor deze groep wordt gereset.
Redenen voor het verzenden van een Prune-bericht:

• Wanneer een multicastpakket de RPF-controle niet doorstaat.
• Wanneer er geen lokaal verbonden clients zijn die een multicastgroep hebben aangevraagd (IGMP Join) en er geen PIM-buren zijn waarnaar multicastverkeer kan worden verzonden (Non-prune Interface).

Graft-bericht.
Laten we ons voorstellen dat R3 geen verkeer van R2 wilde, Prune stuurde en een multicast van R1 ontving. Maar plotseling viel het kanaal tussen R1-R3 weg en zat R3 zonder multicast. U kunt 3 minuten wachten totdat de Prune Timer op R2 afloopt. 3 minuten is een lange wachttijd. Om niet te hoeven wachten, moet u een bericht sturen dat deze S0/1-interface onmiddellijk uit de gesnoeide status naar R2 haalt. Dit bericht zal een Graft-bericht zijn. Na ontvangst van het Graft-bericht zal R2 reageren met een Graft-ACK.
Snoeien overschrijven.

Laten we naar dit diagram kijken. R1 zendt multicast uit naar een segment met twee routers. R3 ontvangt en zendt verkeer uit, R2 ontvangt, maar heeft niemand om verkeer naar uit te zenden. Het stuurt een Prune-bericht naar R1 in dit segment. R1 zou Fa0/0 uit de lijst moeten verwijderen en moeten stoppen met uitzenden in dit segment, maar wat gebeurt er met R3? En R3 zit in hetzelfde segment, ontving ook dit bericht van Prune en begreep de tragedie van de situatie. Voordat R1 stopt met uitzenden, wordt een timer van 3 seconden ingesteld en stopt de uitzending na 3 seconden. 3 seconden - dit is precies hoeveel tijd R3 heeft om zijn multicast niet te verliezen. Daarom stuurt R3 zo snel mogelijk een Pim Join-bericht voor deze groep en denkt R1 er niet meer aan om te stoppen met uitzenden. Over Join-berichten hieronder.
Bericht bevestigen.

Laten we ons deze situatie voorstellen: twee routers zenden tegelijkertijd naar één netwerk uit. Ze ontvangen dezelfde stream van de bron en zenden deze beide uit naar hetzelfde netwerk achter interface e0. Daarom moeten ze bepalen wie de enige echte omroeporganisatie voor dit netwerk zal zijn. Hiervoor worden Assert-berichten gebruikt. Wanneer R2 en R3 duplicatie van multicastverkeer detecteren, dat wil zeggen dat R2 en R3 een multicast ontvangen die zij zelf uitzenden, begrijpen de routers dat er hier iets mis is. In dit geval verzenden routers Assert-berichten, waaronder Administratieve afstand en de routemetriek waarmee de multicast-bron wordt bereikt - 10.1.1.10. De winnaar wordt als volgt bepaald:

1. Degene met een lagere AD.
2. Als AD gelijk is, wie heeft dan de laagste statistiek.
3. Als hier sprake is van gelijkheid, dan is degene die het hogere IP-adres heeft in het netwerk waarnaar zij deze multicast uitzenden.

De winnaar van deze stemming wordt de Designated Router. Pim Hello wordt ook gebruikt om DR's te selecteren. Aan het begin van het artikel werd het PIM Hello-bericht getoond, daar zie je het DR-veld. Degene met het hoogste IP-adres op deze link wint.
Nuttig teken:

MROUTE-tafel.
Na een eerste blik op hoe het PIM-protocol werkt, moeten we begrijpen hoe we met een multicast-routeringstabel moeten werken. In de mroute-tabel wordt informatie opgeslagen over welke streams zijn opgevraagd bij clients en welke streams afkomstig zijn van multicast-servers.
Wanneer bijvoorbeeld op een bepaalde interface een IGMP-lidmaatschapsrapport of PIM-join wordt ontvangen, wordt een record van het type ( *, G ) toegevoegd aan de routeringstabel:

Deze invoer betekent dat er een verkeersverzoek is ontvangen met het adres 238.38.38.38. De DC-vlag betekent dat de multicast in de Dense-modus werkt en C betekent dat de ontvanger rechtstreeks is verbonden met de router, dat wil zeggen dat de router het IGMP-lidmaatschapsrapport en PIM Join heeft ontvangen.
Als er een record is van het type (S,G), betekent dit dat we een multicast-stream hebben:

In het S-veld - 192.168.1.11 hebben we het IP-adres van de multicast-bron geregistreerd. Dit wordt gecontroleerd door de RPF-regel. Als er problemen zijn, moet u eerst in de unicast-tabel de route naar de bron controleren. Geeft in het veld Inkomende interface de interface aan waarop de multicast wordt ontvangen. In een unicast-routeringstabel moet de route naar de bron verwijzen naar de hier opgegeven interface. De uitgaande interface specificeert waar de multicast naartoe wordt omgeleid. Als deze leeg is, heeft de router geen verzoeken voor dit verkeer ontvangen. Meer informatie over alle vlaggen kunt u vinden hier.
PIM Sparse-modus.
De strategie van de Sparse-modus is het tegenovergestelde van de Dense-modus. Wanneer de Sparse-modus multicast-verkeer ontvangt, stuurt het alleen verkeer via die interfaces waar er verzoeken voor deze stroom waren, bijvoorbeeld Pim Join- of IGMP Report-berichten waarin om dit verkeer wordt verzocht.
Soortgelijke elementen voor SM en DM:

• Buurtrelaties worden op dezelfde manier opgebouwd als in PIM DM.
• De RPF-regel werkt.
• De DR-selectie is vergelijkbaar.
• Het mechanisme van Prune Overrides en Assert-berichten is vergelijkbaar.

Om te bepalen wie, waar en welk soort multicast-verkeer op het netwerk nodig is, is een gemeenschappelijk informatiecentrum nodig. Ons centrum wordt Rendezvous Point (RP). Iedereen die een soort multicast-verkeer wil, of iemand die multicast-verkeer van de bron begint te ontvangen, stuurt dit naar RP.
Wanneer de RP multicast-verkeer ontvangt, stuurt hij dit naar de routers die eerder om dit verkeer hebben verzocht.

Laten we ons een topologie voorstellen waarin RP R3 is. Zodra R1 verkeer van S1 ontvangt, kapselt het dit multicastpakket in een unicast PIM Register-bericht in en stuurt het naar RP. Hoe weet hij wie de RP is? In dit geval is het statisch geconfigureerd en zullen we het later hebben over de dynamische RP-configuratie.

ip pim rp-adres 3.3.3.3

RP zal kijken - was er informatie van iemand die dit verkeer graag zou willen ontvangen? Laten we aannemen dat dit niet het geval was. Vervolgens stuurt RP R1 een PIM Register-Stop bericht, wat betekent dat niemand deze multicast nodig heeft, de registratie wordt geweigerd. R1 verzendt geen multicast. Maar de multicast-bronhost zal het verzenden, zodat R1, na ontvangst van Register-Stop, een timer voor registeronderdrukking zal starten die gelijk is aan 60 seconden. 5 seconden voordat deze timer afloopt, stuurt R1 een leeg Register-bericht met een Null-Register-bit (dat wil zeggen zonder een ingekapseld multicast-pakket) naar RP. RP zal op zijn beurt als volgt handelen:

• Als er geen ontvangers zijn, reageert het met een Register-Stop-bericht.
• Als er ontvangers verschijnen, zal hij daar op geen enkele manier op reageren. R1, die niet binnen 5 seconden een weigering heeft ontvangen om te registreren, zal blij zijn en een Register-bericht met een ingekapselde multicast naar RP sturen.

Het lijkt erop dat we erachter zijn gekomen hoe multicast RP bereikt. Laten we nu proberen de vraag te beantwoorden hoe RP verkeer aan ontvangers levert. Hier is het noodzakelijk om een ​​nieuw concept te introduceren: root-path tree (RPT). RPT is een boom die geworteld is in RP, groeit naar de ontvangers en vertakt zich op elke PIM-SM-router. RP maakt het door PIM Join-berichten te ontvangen en voegt een nieuwe tak aan de boom toe. En dat geldt ook voor elke downstream-router. De algemene regel ziet er als volgt uit:

• Wanneer een PIM-SM-router een PIM Join-bericht ontvangt op een andere interface dan de interface waarachter de RP verborgen is, voegt deze een nieuwe vertakking aan de boom toe.
• Er wordt ook een filiaal toegevoegd wanneer de PIM-SM-router een IGMP-lidmaatschapsrapport ontvangt van een direct verbonden host.

Laten we ons voorstellen dat we een multicast-client op de R5-router hebben voor groep 228.8.8.8. Zodra R5 het IGMP-lidmaatschapsrapport van de host ontvangt, stuurt R5 een PIM Join in de richting van de RP, en voegt zelf een interface toe aan de boom die naar de host kijkt. Vervolgens ontvangt R4 PIM Join van R5, voegt interface Gi0/1 toe aan de boom en stuurt PIM Join in de richting van RP. Ten slotte ontvangt RP (R3) PIM Join en voegt Gi0/0 toe aan de boom. De multicast-ontvanger wordt dus geregistreerd. We bouwen een boom met de wortel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Hierna wordt een PIM Join naar R1 verzonden en R1 begint met het verzenden van multicast-verkeer. 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 helemaal niets naar R1 zal sturen.
Als de host plotseling, terwijl een multicast wordt verzonden, deze niet meer wil ontvangen, zal RP, zodra hij een PIM Prune op de Gi0/0-interface ontvangt, onmiddellijk een PIM Register-Stop rechtstreeks naar R1 sturen, en vervolgens een PIM Prune bericht via de Gi0/1-interface. PIM Register-stop wordt via unicast verzonden naar het adres waar het PIM Register vandaan komt.
Zoals we eerder zeiden, zodra een router een PIM Join naar een andere router verzendt, bijvoorbeeld R5 naar R4, wordt er een record toegevoegd aan R4:

En er wordt een timer gestart die R5 voortdurend moet resetten. Deze timer PIM Join-berichten moeten constant worden gereset, anders wordt R4 uitgesloten van de uitgaande lijst. R5 verzendt elke 60 PIM Join-berichten.
Boomomschakeling langs het kortste pad.
We zullen een interface toevoegen tussen R1 en R5 en zien hoe het verkeer stroomt met deze topologie.

Laten we aannemen dat verkeer werd verzonden en ontvangen volgens het oude schema R1-R2-R3-R4-R5, en hier hebben we de interface tussen R1 en R5 aangesloten en geconfigureerd.
Allereerst moeten we de unicast-routeringstabel op R5 opnieuw opbouwen en nu wordt het netwerk 192.168.1.0/24 bereikt via de R5 Gi0/2-interface. Nu begrijpt R5, die multicast ontvangt op interface Gi0/1, dat niet aan de RPF-regel is voldaan en dat het logischer zou zijn om multicast te ontvangen op Gi0/2. Het moet de verbinding met RPT verbreken en een kortere boom bouwen met de naam Shortest-Path Tree (SPT). Om dit te doen, stuurt hij PIM Join naar R0 via Gi2/1 en R1 begint ook een multicast te verzenden via Gi0/2. Nu moet R5 zich afmelden voor RPT om geen twee exemplaren te ontvangen. Om dit te doen, stuurt hij Prune een bericht waarin hij het bron-IP-adres aangeeft en een speciaal bit invoegt: RPT-bit. Dit betekent dat je mij geen verkeer hoeft te sturen, ik heb hier een betere stamboom. RP verzendt ook PIM Prune-berichten naar R1, maar verzendt geen Register-Stop-bericht. Nog een functie: R5 zal nu continu PIM Prune naar RP sturen, terwijl R1 elke minuut PIM Register naar RP blijft sturen. Totdat er geen nieuwe mensen meer zijn die dit verkeer willen, zal RP het weigeren. R5 informeert RP dat het multicast blijft ontvangen via SPT.
Dynamische RP-zoekopdracht.
Auto-RP.
Deze technologie is eigendom van Cisco en is niet bijzonder populair, maar leeft nog steeds. De werking van Auto-RP bestaat uit twee hoofdfasen:
1) RP stuurt RP-Announce-berichten naar het gereserveerde adres - 224.0.1.39, en verklaart zichzelf RP voor iedereen of voor specifieke groepen. Dit bericht wordt elke minuut verzonden.
2) Er is een RP-mapping-agent nodig, die RP-Discovery-berichten verzendt die aangeeft voor welke groepen naar welke RP moet worden geluisterd. Vanuit dit bericht gaan reguliere PIM-routers zelf de RP bepalen. De Mapping Agent kan de RP-router zelf zijn of een afzonderlijke PIM-router. RP-Discovery wordt verzonden naar adres 224.0.1.40 met een timer van één minuut.
Laten we het proces in meer detail bekijken:
Laten we R3 configureren als RP:

ip pim send-rp-announce loopback 0 bereik 10

R2 als mappingagent:

ip pim send-rp-discovery loopback 0 bereik 10

En bij alle anderen verwachten we RP via Auto-RP:

ip pim autorp luisteraar

Zodra we R3 hebben geconfigureerd, begint het met het verzenden van RP-aankondigingen:

En R2 zal, na het instellen van de mapping agent, beginnen te wachten op het RP-Announce-bericht. Pas als het minstens één RP vindt, begint het met het verzenden van RP-Discovery:

Zo weten reguliere routers (PIM RP Listener) zodra ze dit bericht ontvangen, waar ze de RP moeten zoeken.
Een van de grootste problemen met Auto-RP is dat om RP-Announce- en RP-Discovery-berichten te ontvangen, je PIM Join naar de adressen 224.0.1.39-40 moet sturen, en om te kunnen verzenden moet je weten waar de RP is gevestigd. Klassiek kip-en-ei-probleem. Om dit probleem op te lossen is de PIM Sparse-Dense-Mode uitgevonden. Als de router RP niet kent, werkt hij in de Dense-modus; als hij dat wel doet, dan in de Sparse-modus. Wanneer de PIM Sparse-modus en de ip pim autorp-listeneropdracht zijn geconfigureerd op de interfaces van reguliere routers, werkt de router alleen in Dense-modus voor multicasting rechtstreeks vanuit 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 mapping-informatie verzamelt en dit vervolgens aan alle andere routers vertelt. Laten we het proces op dezelfde manier beschrijven als Auto-RP:
1) Zodra we R3 configureren als kandidaat om RP te zijn, met het commando:

ip pim rp-kandidaat loopback 0

Dan zal R3 niets doen; om speciale berichten te kunnen verzenden, moet hij eerst een mapping-agent vinden. We gaan dus verder met de tweede stap.
2) Configureer R2 als mapping-agent:

ip pim bsr-kandidaat loopback 0

R2 begint PIM Bootstrap-berichten te verzenden, waarbij het zichzelf aangeeft als een mapping-agent:

Dit bericht wordt verzonden naar het adres 224.0.013, dat het PIM-protocol ook voor zijn andere berichten gebruikt. Het stuurt ze alle kanten op en daardoor is er geen kip-en-ei-probleem zoals bij Auto-RP.
3) Zodra de RP een bericht ontvangt van de BSR-router, stuurt deze direct een unicast-bericht naar het BSR-routeradres:

Daarna zal de BSR, nadat hij informatie over de RP's heeft ontvangen, deze via multicast naar het adres 224.0.0.13 sturen, waarnaar alle PIM-routers luisteren. Daarom een ​​analoog van het commando ip pim autorp luisteraar voor reguliere routers niet in BSR.
Anycast RP met Multicast Source Discovery Protocol (MSDP).
Met Auto-RP en BSR kunnen we de belasting op RP als volgt verdelen: Elke multicastgroep heeft slechts één actieve RP. Het zal niet mogelijk zijn om de belasting van één multicastgroep over meerdere RP's te verdelen. MSDP doet dit door RP-routers hetzelfde IP-adres te geven met het masker 255.255.255.255. MSDP leert informatie met behulp van een van de methoden: statisch, Auto-RP of BSR.

Op de afbeelding hebben we een Auto-RP-configuratie met MSDP. Beide RP's zijn geconfigureerd met IP-adres 172.16.1.1/32 op de Loopback 1-interface en worden gebruikt voor alle groepen. Met RP-Announce kondigen beide routers zichzelf aan door naar dit adres te verwijzen. De Auto-RP mapping agent stuurt, nadat hij de informatie heeft ontvangen, RP-Discovery over de RP met het adres 172.16.1.1/32. We vertellen routers over het netwerk 172.16.1.1/32 met behulp van IGP en dienovereenkomstig. PIM-routers vragen of registreren dus stromen van de RP die is gespecificeerd als de volgende hop op de route naar het netwerk 172.16.1.1/32. Het MSDP-protocol zelf is ontworpen zodat de RP's zelf berichten over multicast-informatie kunnen uitwisselen.
Beschouw deze topologie:

Switch6 zendt verkeer uit naar het adres 238.38.38.38 en tot nu toe weet alleen RP-R1 hiervan. Switch7 en Switch8 hebben deze groep aangevraagd. Routers R5 en R4 sturen PIM Join respectievelijk naar R1 en R3. Waarom? De route naar 13.13.13.13 voor R5 verwijst naar R1 met behulp van de IGP-metriek, net als voor R4.
RP-R1 is op de hoogte van de stream en zal deze gaan uitzenden richting R5, maar R4 weet er niets van, aangezien R1 deze niet zomaar zal verzenden. Daarom is MSDP noodzakelijk. 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 stroom ontvangen, zullen ze dit aan hun RP-buurman melden.
Zodra RP-R1 een stream van Switch6 ontvangt, verzendt deze onmiddellijk een unicast MSDP Source-Active-bericht, dat informatie bevat zoals (S, G) - informatie over de bron en bestemming van de multicast. Nu RP-R3 weet dat een bron zoals Switch6, wanneer hij een verzoek van R4 voor deze stroom ontvangt, PIM Join naar Switch6 zal sturen, geleid door de routeringstabel. Bijgevolg zal R1, die een dergelijke PIM Join heeft ontvangen, verkeer naar RP-R3 gaan sturen.
MSDP loopt via TCP, RP's sturen elkaar keepalive-berichten om de liveness te controleren. De timer bedraagt ​​60 seconden.
De functie van het verdelen van MSDP-peers in verschillende domeinen blijft onduidelijk, aangezien Keepalive- en SA-berichten geen lidmaatschap van enig domein aangeven. Ook hebben we in deze topologie een configuratie getest die verschillende domeinen aangeeft - er was geen verschil in prestaties.
Als iemand dit kan verduidelijken, lees ik het graag in de reacties.

Bron: www.habr.com