Hur PIM-protokollet fungerar

PIM-protokollet är en uppsättning protokoll för att överföra multicast i ett nätverk mellan routrar. Grannskapsrelationer byggs på samma sätt som i fallet med dynamiska routingprotokoll. PIMv2 skickar Hello-meddelanden var 30:e sekund till den reserverade multicast-adressen 224.0.0.13 (All-PIM-routrar). Meddelandet innehåller Hold Timers - vanligtvis lika med 3.5*Hello Timer, det vill säga 105 sekunder som standard.

PIM använder två huvudsakliga driftlägen - tätt och sparsamt läge. Låt oss börja med tätt läge.
Källbaserade distributionsträd.
Läget för tätt läge är tillrådligt att använda i fallet med ett stort antal klienter i olika multicast-grupper. När en router tar emot multicast-trafik är det första den gör att kontrollera den för RPF-regeln. RPF - den här regeln används för att kontrollera källan till en multicast med en unicast-dirigeringstabell. Det är nödvändigt att trafiken kommer till gränssnittet bakom vilket denna värd är gömd enligt versionen av unicast-routningstabellen. Denna mekanism löser problemet med en loop som uppstår under multicast-överföring.

R3 kommer att känna igen multicast-källan (Source IP) från multicast-meddelandet och kontrollera de två flödena från R1 och R2 med hjälp av dess unicast-tabell. Strömmen från gränssnittet som tabellen pekar på (R1 till R3) kommer att sändas vidare, och strömmen från R2 kommer att släppas, eftersom för att komma till multicastkällan måste du skicka paket via S0/1.
Frågan är vad som händer om du har två likvärdiga rutter med samma mätvärde? I det här fallet kommer routern att välja nästa hopp från dessa rutter. Den som har den högre IP-adressen vinner. Om du behöver ändra detta beteende kan du använda ECMP. Fler detaljer här.
Efter att ha kontrollerat RPF-regeln skickar routern ett multicast-paket till alla sina PIM-grannar, förutom den från vilken paketet togs emot. Andra PIM-routrar upprepar denna process. Sökvägen som ett multicast-paket har tagit från källan till de slutliga mottagarna bildar ett träd som kallas källbaserat distributionsträd, kortaste vägträd (SPT), källträd. Tre olika namn, välj vilket som helst.
Hur man löser problemet att vissa routrar inte gav upp på någon multicastström och det finns ingen att skicka den till, utan uppströmsroutern skickar den till honom. Prune-mekanismen uppfanns för detta.
Beskär meddelande.
Till exempel kommer R2 att fortsätta att skicka en multicast till R3, även om R3, enligt RPF-regeln, släpper den. Varför ladda kanalen? R3 skickar ett PIM Prune-meddelande och R2, när han tar emot detta meddelande, kommer att ta bort gränssnitt S0/1 från den utgående gränssnittslistan för detta flöde, listan över gränssnitt från vilka denna trafik ska skickas.

Följande är en mer formell definition av ett PIM Prune-meddelande:
PIM Prune-meddelandet skickas av en router till en andra router för att få den andra routern att ta bort länken på vilken Prune tas emot från en viss (S,G) SPT.

Efter att ha tagit emot beskärningsmeddelandet ställer R2 in beskärningstimern på 3 minuter. Efter tre minuter kommer den att börja skicka trafik igen tills den får ett nytt Prune-meddelande. Detta är i PIMv1.
Och i PIMv2 har en State Refresh-timer lagts till (60 sekunder som standard). Så snart ett beskärningsmeddelande har skickats från R3, startas denna timer på R3. Efter utgången av denna timer kommer R3 att skicka ett State Refresh-meddelande, vilket återställer 3-minuters beskärningstimern på R2 för denna grupp.
Skäl till att skicka ett beskärningsmeddelande:

• När ett multicast-paket misslyckas med RPF-kontrollen.
• När det inte finns några lokalt anslutna klienter som har begärt en multicast-grupp (IGMP Join) och det inte finns några PIM-grannar som multicast-trafik kan skickas till (Non-prune Interface).

Graft meddelande.
Låt oss föreställa oss att R3 inte ville ha trafik från R2, skickade Prune och fick en multicast från R1. Men plötsligt föll kanalen mellan R1-R3 och R3 blev utan multicast. Du kan vänta 3 minuter tills beskärningstimern på R2 går ut. 3 minuter är en lång väntan, för att inte vänta måste du skicka ett meddelande som omedelbart kommer att ta detta S0/1-gränssnitt till R2 ur det beskärda tillståndet. Detta meddelande kommer att vara ett graftmeddelande. Efter att ha mottagit Graft-meddelandet kommer R2 att svara med en Graft-ACK.
Åsidosätt beskärning.

Låt oss titta på detta diagram. R1 sänder multicast till ett segment med två routrar. R3 tar emot och sänder trafik, R2 tar emot, men har ingen att sända trafik till. Den skickar ett beskärningsmeddelande till R1 i detta segment. R1 borde ta bort Fa0/0 från listan och sluta sända i detta segment, men vad kommer att hända med R3? Och R3 är i samma segment, fick också detta meddelande från Prune och förstod tragedin i situationen. Innan R1 slutar sända ställer den in en timer på 3 sekunder och slutar sända efter 3 sekunder. 3 sekunder - det här är exakt hur mycket tid R3 har för att inte förlora sin multicast. Därför skickar R3 ett Pim Join-meddelande för denna grupp så snart som möjligt, och R1 tänker inte längre på att sluta sända. Om Gå med meddelanden nedan.
Påstå meddelande.

Låt oss föreställa oss den här situationen: två routrar sänder till ett nätverk samtidigt. De tar emot samma ström från källan, och båda sänder den till samma nätverk bakom gränssnittet e0. Därför måste de bestämma vem som kommer att vara den enda sändaren för detta nätverk. Påstå meddelanden används för detta. När R2 och R3 upptäcker duplicering av multicast-trafik, det vill säga R2 och R3 tar emot en multicast som de själva sänder, förstår routrarna att något är fel här. I det här fallet skickar routrar Assert-meddelanden, som inkluderar administrativt avstånd och ruttmåttet med vilket multicast-källan nås - 10.1.1.10. Vinnaren bestäms enligt följande:

1. Den med lägre AD.
2. Om AD är lika, vem har då den lägre måtten.
3. Om det är jämlikhet här, så den som har den högre IP-adressen i nätverket som de sänder denna multicast till.

Vinnaren av denna omröstning blir Designated Router. Pim Hello används också för att välja DRs. I början av artikeln visades PIM Hello-meddelandet, du kan se DR-fältet där. Den som har högst IP-adress på denna länk vinner.
Användbart tecken:

MROUTE-tabell.
Efter en första titt på hur PIM-protokollet fungerar måste vi förstå hur man arbetar med en multicast-routningstabell. Mroute-tabellen lagrar information om vilka strömmar som begärdes från klienter och vilka strömmar som flödar från multicast-servrar.
Till exempel, när en IGMP-medlemsrapport eller PIM-anslutning tas emot på något gränssnitt, läggs en post av typen (*, G) till i routingtabellen:

Denna post betyder att en trafikförfrågan mottogs med adressen 238.38.38.38. DC-flaggan betyder att multicasten kommer att fungera i tätt läge och C betyder att mottagaren är direkt ansluten till routern, det vill säga routern fick IGMP Membership Report och PIM Join.
Om det finns en post av typen (S,G) betyder det att vi har en multicast-ström:

I S-fältet - 192.168.1.11 har vi registrerat IP-adressen för multicast-källan, det är denna som kommer att kontrolleras av RPF-regeln. Om det finns problem är det första du behöver göra att kontrollera unicast-tabellen för vägen till källan. I fältet Inkommande gränssnitt indikerar gränssnittet till vilket multicasten tas emot. I en unicast-dirigeringstabell måste rutten till källan referera till det gränssnitt som anges här. Det utgående gränssnittet anger vart multicasten kommer att omdirigeras. Om den är tom har routern inte fått några förfrågningar om denna trafik. Mer information om alla flaggor finns här.
PIM Sparse-läge.
Strategin för Sparse-mode är motsatsen till dense-mode. När Sparse-mode tar emot multicast-trafik kommer det bara att skicka trafik genom de gränssnitt där det fanns förfrågningar om detta flöde, till exempel Pim Join eller IGMP Report-meddelanden som begär denna trafik.
Liknande element för SM och DM:

• Grannskapsrelationer byggs på samma sätt som i PIM DM.
• RPF-regeln fungerar.
• DR-valet är liknande.
• Mekanismen för Prune Overrides och Assert-meddelanden är liknande.

För att styra vem, var och vilken sorts multicast-trafik som behövs på nätet behövs ett gemensamt informationscenter. Vårt centrum kommer att vara Rendezvous Point (RP). Den som vill ha någon form av multicast-trafik eller någon började ta emot multicast-trafik från källan, då skickar han det till RP.
När RP:n tar emot multicast-trafik kommer den att skicka den till de routrar som tidigare begärt denna trafik.

Låt oss föreställa oss en topologi där RP är R3. Så snart R1 tar emot trafik från S1, kapslar den in detta multicast-paket i ett unicast PIM-registermeddelande och skickar det till RP. Hur vet han vem RP är? I det här fallet är det konfigurerat statiskt, och vi kommer att prata om dynamisk RP-konfiguration senare.

ip pim rp-adress 3.3.3.3

RP kommer att titta - fanns det information från någon som skulle vilja ta emot denna trafik? Låt oss anta att det inte var det. Då kommer RP att skicka R1 ett PIM Register-Stop meddelande, vilket betyder att ingen behöver denna multicast, registrering nekas. R1 skickar inte multicast. Men multicastkällvärden kommer att skicka det, så att R1, efter att ha mottagit Register-Stop, kommer att starta en Register-Suppression-timer lika med 60 sekunder. 5 sekunder innan denna timer går ut kommer R1 att skicka ett tomt registermeddelande med en nollregistreringsbit (det vill säga utan ett inkapslat multicastpaket) mot RP. RP kommer i sin tur att agera så här:

• Om det inte fanns några mottagare kommer den att svara med ett Registrera-Stopp-meddelande.
• Om mottagare dyker upp kommer han inte att svara på det på något sätt. R1, som inte har fått en vägran att registrera sig inom 5 sekunder, kommer att vara glad och skicka ett registermeddelande med en inkapslad multicast till RP.

Vi verkar ha listat ut hur multicast når RP, låt oss nu försöka svara på frågan om hur RP levererar trafik till mottagare. Här är det nödvändigt att introducera ett nytt koncept - root-path tree (RPT). RPT är ett träd rotat i RP, som växer mot mottagarna och förgrenar sig på varje PIM-SM-router. RP skapar den genom att ta emot PIM Join-meddelanden och lägger till en ny gren i trädet. Och så gör varje nedströms router. Den allmänna regeln ser ut så här:

• När en PIM-SM-router tar emot ett PIM Join-meddelande på något annat gränssnitt än gränssnittet bakom vilket RP:n är gömd, lägger den till en ny gren till trädet.
• En gren läggs också till när PIM-SM-routern tar emot en IGMP-medlemsrapport från en direktansluten värd.

Låt oss föreställa oss att vi har en multicast-klient på R5-routern för grupp 228.8.8.8. Så snart R5 tar emot IGMP-medlemsrapporten från värden, skickar R5 en PIM Join i riktning mot RP, och lägger själv till ett gränssnitt till trädet som tittar på värden. Därefter tar R4 emot PIM Join från R5, lägger till gränssnitt Gi0/1 till trädet och skickar PIM Join i riktning mot RP. Slutligen tar RP ( R3 ) emot PIM Join och lägger till Gi0/0 i trädet. Således är multicast-mottagaren registrerad. Vi bygger ett träd med roten R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Efter detta kommer en PIM Join att skickas till R1 och R1 kommer att börja skicka multicast-trafik. Det är viktigt att notera att om värden begärde trafik innan multicast-sändningen började, kommer RP inte att skicka PIM Join och kommer inte att skicka något till R1 alls.
Om plötsligt medan en multicast sänds slutar värden att vilja ta emot den, så snart RP tar emot en PIM Prune på Gi0/0-gränssnittet kommer den omedelbart att skicka ett PIM Register-Stop direkt till R1, och sedan en PIM Prune meddelande via Gi0/1-gränssnittet. PIM Register-stop skickas via unicast till den adress som PIM-registret kom ifrån.
Som vi sa tidigare, så snart en router skickar en PIM Join till en annan, till exempel R5 till R4, läggs en post till R4:

Och en timer startas som R5 konstant måste återställa denna timer PIM Join-meddelanden konstant, annars kommer R4 att exkluderas från den utgående listan. R5 kommer att skicka var 60:e PIM Join-meddelande.
Byte av träd på kortaste vägen.
Vi kommer att lägga till ett gränssnitt mellan R1 och R5 och se hur trafiken flyter med denna topologi.

Låt oss anta att trafik skickades och togs emot enligt det gamla schemat R1-R2-R3-R4-R5, och här kopplade vi och konfigurerade gränssnittet mellan R1 och R5.
Först och främst måste vi bygga om unicast-routningstabellen på R5 och nu nås nätverket 192.168.1.0/24 via R5 Gi0/2-gränssnittet. Nu förstår R5, som tar emot multicast på gränssnittet Gi0/1, att RPF-regeln inte är uppfylld och det skulle vara mer logiskt att ta emot multicast på Gi0/2. Den ska koppla från RPT och bygga ett kortare träd som kallas Shortest-Path Tree (SPT). För att göra detta skickar han PIM Join till R0 till Gi2/1 och R1 börjar skicka en multicast även genom Gi0/2. Nu behöver R5 avregistrera sig från RPT för att inte få två exemplar. För att göra detta skickar han ett meddelande till Prune som anger källans IP-adress och infogar en speciell bit - RPT-bit. Det betyder att du inte behöver skicka trafik till mig, jag har ett bättre träd här. RP skickar också PIM Prune-meddelanden till R1, men skickar inte ett Register-Stop-meddelande. En annan funktion: R5 kommer nu kontinuerligt att skicka PIM Prune till RP, eftersom R1 fortsätter att skicka PIM Register till RP varje minut. Tills det inte finns några nya personer som vill ha denna trafik, kommer RP att vägra den. R5 meddelar RP att den fortsätter att ta emot multicast via SPT.
Dynamisk RP-sökning.
Auto-RP.
Denna teknik är egenutvecklad från Cisco och är inte särskilt populär, men är fortfarande vid liv. Auto-RP-drift består av två huvudsteg:
1) RP skickar RP-Announce-meddelanden till den reserverade adressen - 224.0.1.39, och förklarar sig RP antingen för alla eller för specifika grupper. Detta meddelande skickas varje minut.
2) En RP-mappningsagent krävs, som skickar RP-Discovery-meddelanden som indikerar för vilka grupper som RP ska lyssnas på. Det är från detta meddelande som vanliga PIM-routrar kommer att bestämma RP för sig själva. Kartläggningsagenten kan antingen vara själva RP-routern eller en separat PIM-router. RP-Discovery skickas till adress 224.0.1.40 med en timer på en minut.
Låt oss titta på processen mer i detalj:
Låt oss konfigurera R3 som RP:

ip pim send-rp-announce loopback 0 scope 10

R2 som kartläggningsmedel:

ip pim send-rp-discovery loopback 0 scope 10

Och på alla andra kommer vi att förvänta oss RP via Auto-RP:

ip pim autorp lyssnare

När vi har konfigurerat R3 kommer den att börja skicka RP-Announce:

Och R2, efter att ha ställt in mappningsagenten, börjar vänta på RP-Announce-meddelandet. Först när den hittar minst en RP kommer den att börja skicka RP-Discovery:

På detta sätt, så snart vanliga routrar (PIM RP Listener) tar emot detta meddelande, kommer de att veta var de ska leta efter RP.
Ett av huvudproblemen med Auto-RP är att för att kunna ta emot RP-Announce och RP-Discovery-meddelanden måste du skicka PIM Join till adresserna 224.0.1.39-40, och för att kunna skicka måste du veta var RP finns. Klassiskt kyckling- och äggproblem. För att lösa detta problem uppfanns PIM Sparse-Dense-Mode. Om routern inte känner till RP, fungerar den i tätt läge, om det gör det i sparsalt läge. När PIM Sparse-mode och ip pim autorp listener-kommandot är konfigurerade på gränssnitten för vanliga routrar, kommer routern att fungera i tätt läge endast för multicasting direkt från Auto-RP-protokollet (224.0.1.39-40).
BootStrap Router (BSR).
Denna funktion fungerar på samma sätt som Auto-RP. Varje RP skickar ett meddelande till karteringsagenten, som samlar in kartinformation och sedan berättar för alla andra routrar. Låt oss beskriva processen på samma sätt som Auto-RP:
1) När vi konfigurerat R3 som en kandidat för att vara RP, med kommandot:

ip pim rp-kandidat loopback 0

Då kommer inte R3 att göra någonting, för att börja skicka specialmeddelanden måste han först hitta en kartläggningsagent. Så vi går vidare till det andra steget.
2) Konfigurera R2 som en kartläggningsagent:

ip pim bsr-kandidat loopback 0

R2 börjar skicka PIM Bootstrap-meddelanden, där den indikerar sig själv som en kartläggningsagent:

Detta meddelande skickas till adressen 224.0.013, som PIM-protokollet också använder för sina andra meddelanden. Det skickar dem åt alla håll och därför finns det inget problem med kyckling och ägg som det var i Auto-RP.
3) Så snart RP tar emot ett meddelande från BSR-routern kommer den omedelbart att skicka ett unicast-meddelande till BSR-routerns adress:

Därefter kommer BSR, efter att ha fått information om RP:erna, att skicka dem med multicast till adressen 224.0.0.13, som lyssnas på av alla PIM-routrar. Därför en analog av kommandot ip pim autorp lyssnare för vanliga routrar som inte finns i BSR.
Anycast RP med Multicast Source Discovery Protocol (MSDP).
Auto-RP och BSR tillåter oss att fördela belastningen på RP enligt följande: Varje multicast-grupp har bara en aktiv RP. Det kommer inte att vara möjligt att fördela belastningen för en multicast-grupp över flera RP:er. MSDP gör detta genom att ge RP-routrar samma IP-adress med en mask på 255.255.255.255. MSDP lär sig information med hjälp av en av metoderna: statisk, Auto-RP eller BSR.

På bilden har vi en Auto-RP-konfiguration med MSDP. Båda RP:erna är konfigurerade med IP-adress 172.16.1.1/32 på Loopback 1-gränssnittet och används för alla grupper. Med RP-Announce meddelar båda routrarna sig själva genom att hänvisa till denna adress. Auto-RP-mappningsagenten, efter att ha mottagit informationen, skickar RP-Discovery om RP:n med adressen 172.16.1.1/32. Vi berättar för routrar om nätverket 172.16.1.1/32 med hjälp av IGP och i enlighet därmed. Således begär eller registrerar PIM-routrar flöden från den RP som är specificerad som nästa hopp på rutten till nätverket 172.16.1.1/32. Själva MSDP-protokollet är utformat för att RP:erna själva ska utbyta meddelanden om multicast-information.
Tänk på denna topologi:

Switch6 sänder trafik till adressen 238.38.38.38 och än så länge vet bara RP-R1 om det. Switch7 och Switch8 begärde denna grupp. Routrarna R5 och R4 skickar PIM Join till R1 respektive R3. Varför? Rutten till 13.13.13.13 för R5 kommer att referera till R1 med IGP-måttet, precis som för R4.
RP-R1 känner till strömmen och kommer att börja sända den mot R5, men R4 vet ingenting om den, eftersom R1 inte bara skickar den. Därför är MSDP nödvändigt. Vi konfigurerar det på R1 och R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 på R1

ip msdp peer 1.1.1.1 connect-source Loopback3 på R3

De kommer att ta upp en session mellan varandra och när de tar emot något flöde kommer de att rapportera det till sin RP-granne.
Så snart RP-R1 tar emot en ström från Switch6 kommer den omedelbart att skicka ett unicast MSDP Source-Active-meddelande, som kommer att innehålla information som (S, G) - information om källan och destinationen för multicasten. Nu när RP-R3 vet att en källa som Switch6, när den tar emot en begäran från R4 för detta flöde, kommer den att skicka PIM Join mot Switch6, guidad av routingtabellen. Följaktligen kommer R1 som har mottagit en sådan PIM Join att börja skicka trafik mot RP-R3.
MSDP körs över TCP, RP:er skickar varandra keepalive-meddelanden för att kontrollera livlighet. Timern är 60 sekunder.
Funktionen att dela upp MSDP-peers i olika domäner är fortfarande oklar, eftersom Keepalive- och SA-meddelanden inte indikerar medlemskap i någon domän. I denna topologi testade vi också en konfiguration som indikerar olika domäner - det fanns ingen skillnad i prestanda.
Om någon kan förtydliga så läser jag det gärna i kommentarerna.

Källa: will.com