Principer för PIM-protokollet

PIM-protokollet är en uppsättning protokoll för överföring av multicast i nätverk mellan routrar. Grannskapsrelationer byggs på samma sätt som i fallet med dynamiska routingprotokoll. PIMv2 skickar var 30:e sekund ett Hello-meddelande till den reserverade multicastadressen 224.0.0.13 (All-PIM-Routers). Meddelandet innehåller hålltimrar — som vanligtvis är 3,5 gånger Hello-timern, det vill säga 105 sekunder som standard.

PIM använder två grundläggande driftslägen — Dense och Sparse mode. Låt oss börja med Dense mode.
Källbaserade distributions-träd.
Dense-mode-läget är lämpligt att använda när det finns ett stort antal klienter i olika multicastgrupper. När en router tar emot multicast-trafik, kontrollerar den först den mot RPF-regeln. RPF — denna regel används för att verifiera källan för multicast mot unicast-routingtabellen. Trafiken måste komma in på det gränssnitt där den aktuella värden döljer sig enligt den unicast-routingtabellen. Denna mekanism löser problemet med slinga vid överföring av multicast.

R3 får från multicast-meddelandet veta källan för multicast (Source IP) och kontrollerar två strömmar från R1 och R2 i sin unicast-routingtabell. Strömmen från det gränssnitt som tabellen pekar på (R1 till R3) kommer att vidarebefordras, medan strömmen från R2 kommer att släppas, eftersom för att nå multicast-källan måste paketen skickas via S0/1.
Frågan är, vad händer om ni har två ekvivalenta rutter med samma metrik? I det här fallet kommer routern att välja baserat på next-hop för dessa rutter. Den med högre IP-adress vinner. Om det är nödvändigt att ändra detta beteende kan ECMP användas. Mer information ). Ett typiskt exempel på användning:.
Efter att ha kontrollerat RPF-regeln skickar routern multicast-paketet till alla sina PIM-grannar, förutom den från vilken paketet mottogs. Övriga PIM-routrar upprepar denna process. Vägen som multicast-paketet tog från källan till slutmålen bildar ett träd som kallas — källbaserat distributions-träd, shortest-path tree (SPT), källträd. Tre olika namn, välj vilket som helst.
Hur ska man hantera frågan om vissa routrar inte lyckades få något multicast-flöde att skicka, och den överordnade routern skickar det till dem? För detta har prune-mekanismen uppfunnits.
Prune-meddelande.
Till exempel, R2 fortsätter att skicka multicast till R3, även om R3 släpper den enligt RPF-regeln. Varför belasta kanalen? R3 skickar PIM Prune-meddelandet och R2, när det mottar detta meddelande, kommer att ta bort gränssnittet S0/1 från listan (outgoing interface list) för den aktuella strömmen, listan över gränssnitt som ska skicka denna trafik.

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-meddelandet tas emot från en viss (S,G) SPT.

Efter att ha mottagit Prune-meddelandet, ställer R2 in Prune-timern till 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.
I PIMv2 har dessutom en State Refresh-timer lagts till (standard är 60 sekunder). Så snart ett Prune-meddelande skickas från R3, startas denna timer på R3. När timern löper ut, kommer R3 att skicka ett State Refresh-meddelande som återställer R2:s 3-minuters Prune Timer för den aktuella gruppen.
Anledningar till att skicka Prune-meddelandet:

• När multicast-paketet inte passerade RPF-kontrollen.
• När det inte finns några lokalt anslutna kunder som begärt multicastgruppen (IGMP Join) och inga PIM-grannar att skicka multicasttrafik till (Non-prune Interface).

Graft-meddelande.
Anta att R3 inte ville ha trafik från R2, skickade Prune och tog emot multicast från R1. Men plötsligt föll länken mellan R1 och R3 och R3 blev utan multicast. Man kan vänta 3 minuter tills R2:s Prune Timer löper ut. Att vänta 3 minuter är länge, för att inte behöva vänta måste ett meddelande skickas som omedelbart avlägsnar detta gränssnitt S0/1 på R2 från det prunade tillståndet. Detta meddelande är Graft-meddelandet. Efter att ha mottagit Graft-meddelandet, kommer R2 att skicka ett svar, Graft-ACK.
Prune Override.

Låt oss titta på detta schema. R1 sänder multicast till segmentet med två routrar. R3 tar emot och sänder trafiken, medan R2 tar emot, men har ingen att sända trafiken till. Han skickar ett Prune-meddelande till R1 i detta segment. R1 måste ta bort Fa0/0 från listan och sluta sända i detta segment, men vad händer med R3? R3 är i samma segment, har också mottagit detta Prune-meddelande och förstår allvaret i situationen. Innan R1 slutar sända ställer han in en timer på 3 sekunder och slutar sända efter 3 sekunder. 3 sekunder – det är den tid R3 har för att inte förlora sin multicast. Därför skickar R3 så snart som möjligt ett Pim Join-meddelande för denna grupp och R1 tänker inte längre på att sluta sända. Mer om Join-meddelanden nedan.
Assert-meddelande.

Tänk dig en situation där 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 ett nätverk via gränssnittet e0. Därför måste de avgöra vem som blir den enda sändaren för detta nätverk. För detta används Assert-meddelanden. När R2 och R3 upptäcker duplikering av multicast-trafik, det vill säga när multicast som de själva sänder kommer till R2 och R3, förstår routrarna att något är fel. I detta fall skickar routrarna Assert-meddelanden som inkluderar Administrative Distance och metrik för den väg som når multicast-källan – 10.1.1.10. Vinnaren avgörs så här:

1. Den med lägst AD.
2. Om AD är lika, den med lägst metrik.
3. Om det fortfarande är jämt, den med högst IP-adress i nätverket där de sänder denna multicast.

Den som vinner denna omröstning blir Designated Router. För att välja DR används även Pim Hello. I början av artikeln visades PIM Hello-meddelandet, där DR-fältet kan observeras. Den med högst IP-adress på denna länk vinner.
Nyttig tabell:

MROUTE-tabell.
Efter en första genomgång av hur PIM-protokollet fungerar, måste vi förstå hur vi ska arbeta med multicast-routningstabellen. I mroute-tabellen lagras information om vilka strömmar som har begärts av klienterna och vilka strömmar som sänds från multicastservrar.
Till exempel, när ett IGMP Membership Report eller PIM Join mottas på ett visst gränssnitt, läggs en post av typen ( *, G ) till i routingtabeln:

Denna post innebär att en begäran om trafik har erhållits från adressen 238.38.38.38. Flaggan DC innebär att multicast kommer att fungera i Dense mode och C står för att mottagaren är direkt ansluten till routern, vilket innebär att routern har erhållit ett IGMP Membership Report och PIM Join.
Om det finns en post av typen (S,G) innebär det att vi har en multicastström:

I fältet S — 192.168.1.11, har vi angivit IP-adressen för multicastkällan, vilket är den som kommer att kontrolleras av RPF-regeln. Vid problem är det första som måste kontrolleras unicast-tabellen för en rutt till källan. I fältet Incoming Interface anges det gränssnitt som multicast tas emot på. I unicast-ruttabellen ska rutten till källan hänvisa till det gränssnitt som anges här. I Outgoing Interface anges vart multicast kommer att dirigeras. Om det är tomt, betyder det att det inte har inkommit några begärningar om denna trafik till routern. Mer information om alla flaggor kan hittas här.
PIM Sparse-mode.
Strategin Sparse-mode är motsatsen till Dense-mode. När Sparse-mode tar emot multicasttrafik, kommer den att skicka trafiken endast genom de gränssnitt där det har kommit begärningar om denna ström, till exempel Pim Join eller IGMP Report-meddelanden med begäran om denna trafik.
Likheterna mellan SM och DM:

• Grannskapsrelationer byggs också, precis som i PIM DM.
• RPF-regeln fungerar.
• Valet av DR är liknande.
• Mechanismen Prune Overrides och Assert-meddelanden är likartade.

För att kontrollera vem, var och vilken multicasttrafik som behövs i nätverket, behövs ett gemensamt informationscentrum. Detta centrum kommer att vara Rendezvous Point (RP). Alla som vill ha viss multicasttrafik eller den som börjar ta emot multicasttrafik från källan, kommer att skicka den till RP.
När RP får multicasttrafik kommer den att skicka den till de routrar som tidigare har begärt denna trafik.

Anta en sådan topologi där RP är R3. Så snart R1 får trafik från S1, kommer den att inkapsla detta multicastpaket i ett unicast PIM Register-meddelande och skicka det till RP. Hur vet den vem RP är? I detta fall är den statiskt konfigurerad, och vi kommer att diskutera dynamisk konfiguration av RP senare.

ip pim rp-address 3.3.3.3

RP kommer att kontrollera om det finns information från någon som önskar ta emot denna trafik. Anta att det inte finns någon sådan information. Då kommer RP att skicka ett Register-Stop-meddelande till R1, vilket innebär att ingen behöver denna multicast och registreringen avvisas. R1 kommer inte att skicka multicast. Men källan för multicast kommer att fortsätta att sända, så R1, efter att ha fått Register-Stop, kommer att starta en timer för Register-Suppression, som är inställd på 60 sekunder. Fem sekunder innan denna timer går ut, kommer R1 att skicka ett tomt Register-meddelande med Null-Register-biten (det vill säga utan inkapslat multicast-paket) till RP. RP kommer å sin sida att agera på följande sätt:

• Om det inte fanns några mottagare, så svarar han med ett Register-Stop-meddelande.
• Om mottagarna dyker upp, kommer han inte att svara på det. Om R1 inte får någon avvisning på sin registrering inom 5 sekunder, kommer han att bli glad och skicka ett Register-meddelande med inkapslat multicast till RP.

Nu har vi förstått hur multicast når RP, så låt oss besvara frågan om hur RP förmedlar trafiken till mottagarna. Här behöver vi introducera ett nytt begrepp - root-path tree (RPT). RPT är ett träd med roten i RP, som växer mot mottagarna och grenar sig vid varje PIM-SM-router. RP skapar det genom att ta emot PIM Join-meddelanden och lägger till en ny gren i trädet. Detta gör varje lägre router.

• När en PIM-SM-router tar emot ett PIM Join-meddelande på någon gränssnitt, med undantag för gränssnittet bakom vilket RP döljer sig, lägger den till en ny gren i trädet.
• En gren läggs också till när en PIM-SM-router får en IGMP Membership Report från en direkt ansluten värd.

Anta att vi har en multicast-klient på routern R5 för gruppen 228.8.8.8. Så snart R5 får en IGMP Membership Report från värden, skickar R5 ett PIM Join-meddelande i riktning mot RP och lägger själv till gränssnittet som är riktat mot värden till trädet. Därefter får R4 PIM Join från R5, lägger till gränssnittet Gi0/1 i trädet och skickar PIM Join i riktning mot RP. Slutligen får RP (R3) PIM Join och lägger till Gi0/0 i trädet. Så skapas registreringen av multicast-mottagaren. Vi bygger ett träd med roten R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Efter detta kommer en PIM Join skickas till R1 och R1 kommer börja sända multicast trafik. Det är viktigt att notera att om värden begärde trafik innan multicast sändningen började, så kommer RP inte att skicka en PIM Join och överhuvudtaget inte skicka något till R1.
Om det skulle hända att värden slutar vilja ta emot multicast medan det fortfarande skickas, så snart RP får en PIM Prune på gränssnittet Gi0/0, kommer det omedelbart att skicka en PIM Register-Stop direkt till R1, och därefter en PIM Prune-meddelande via gränssnittet Gi0/1. PIM Register-Stop skickas unicast till den adress som PIM Register kom ifrån.
Som vi nämnde tidigare, så snart routern skickar PIM Join till en annan, exempelvis R5 till R4, så läggs en post till i R4:

Och en timer startas, som R5 ständigt måste återställa med PIM Join meddelanden, annars kommer R4 att undanta den från outgoing list. R5 kommer att skicka PIM Join-meddelanden var 60:e sekund.
Switchover av kortaste vägensträdet.
Vi kommer att lägga till ett gränssnitt mellan R1 och R5 och se hur trafiken flödar med denna topologi.

Låt oss anta att trafiken skickades och mottogs enligt det gamla schemat R1-R2-R3-R4-R5 och nu har vi kopplat och konfigurerat gränssnittet mellan R1 och R5.
Först kommer vår unicast-routingtabell på R5 att omstruktureras och nu når nätverket 192.168.1.0/24 via gränssnittet R5 Gi0/2. Nu, när R5 tar emot multicast på gränssnittet Gi0/1, förstår den att RPF-regeln inte uppfylls och det skulle vara mer logiskt att ta emot multicast via Gi0/2. Den måste koppla bort från RPT och bygga ett kortare träd, som kallas Shortest-Path Tree (SPT). För detta skickar den en PIM Join till R1 via Gi0/2 och R1 börjar sända multicast även via Gi0/2. Nu måste R5 avsäga sig RPT för att inte ta emot två kopior. För detta skickar den ett Prune-meddelande som anger källans IP-adress och inkluderar en speciell bit — RPT-bit. Detta betyder att jag inte vill ha trafik skickad till mig, jag har ett bättre träd här. RP skickar också PIM Prune-meddelanden mot R1, men skickar inte Register-Stop-meddelandet. En annan funktion är att R5 nu ständigt kommer att skicka PIM Prune till RP, eftersom R1 fortsätter att skicka PIM Register till RP varje minut. RP kommer att svara med ett avslag så länge det inte finns några nya intressenter för denna trafik. R5 meddelar RP att det fortsätter ta emot multicast via SPT.
Dynamisk sökning av RP.
Auto-RP.
Denna teknik är proprietär från Cisco och är inte särskilt populär, men den lever fortfarande kvar. Auto-RP:s funktion består av två huvudaspekter:
1) RP skickar RP-Announce-meddelanden till den reserverade adressen — 224.0.1.39, där den annonserar sig själv som RP för antingen alla eller vissa specifika grupper. Detta meddelande skickas varje minut.
2) En RP-mapping agent är nödvändig, som kommer att skicka RP-Discovery-meddelanden med information om vilken RP som ska lyssnas på för vilka grupper. Från detta meddelande kommer vanliga PIM-router att avgöra vilken RP de ska använda. Mapping Agent kan vara antingen den egna RP-routern eller en separat PIM-router. RP-Discovery skickas till adressen 224.0.1.40 med en timer på en minut.
Låt oss titta på processen mer detaljerat:
Vi konfigurerar R3 som RP:

ip pim send-rp-announce loopback 0 scope 10

R2 som mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

Och på alla andra kommer vi att vänta på RP via Auto-RP:

ip pim autorp listener

Så snart vi konfigurerar R3 kommer den att börja skicka RP-Announce:

Och R2, efter att ha konfigurerats som mapping agent, kommer att börja vänta på RP-Announce-meddelanden. Endast när den hittar minst en RP kommer den att börja skicka RP-Discovery:

Således, så snart vanliga routrar (PIM RP Listener) mottar detta meddelande, vet de var de ska leta efter RP.
Ett av de främsta problemen med Auto-RP är att för att ta emot RP-Announce och RP-Discovery-meddelanden måste man skicka PIM Join till adresserna 224.0.1.39-40, och för att kunna skicka dem måste man veta var RP befinner sig. Den klassiska hönan och ägget-problemet. För att lösa detta problem skapades PIM Sparse-Dense-Mode. Om routern inte känner till RP kommer den att arbeta i Dense-mode, om den vet, kommer den att arbeta i Sparse-mode. När PIM Sparse-mode och kommandot ip pim autorp listener är inställda på gränssnitten av de vanliga routrarna kommer routern att arbeta i Dense-mode endast för multicast direkt relaterat till Auto-RP-protokollet (224.0.1.39-40).
BootStrap Router (BSR).
Denna funktion fungerar på ett liknande sätt som Auto-RP. Varje RP skickar ett meddelande till mapping agenten, som samlar mappinginformation och därefter informerar alla andra routrar. Vi beskriver processen på samma sätt som Auto-RP:
1) Så snart vi konfigurerar R3 som kandidat att bli RP, med kommandot:

ip pim rp-candidate loopback 0

Kommer R3 inte att göra något, för att börja skicka speciella meddelanden måste den först hitta en mapping agent. Således går vi vidare till steg två.
2) Vi ställer in R2 som mapping agent:

ip pim bsr-kandidat loopback 0

R2 börjar skicka PIM Bootstrap-meddelanden där den anger sig själv som mapping agent:

Detta meddelande skickas till adress 224.0.0.13, som PIM-protokollet använder även för sina andra meddelanden. Det sänder dem i alla riktningar och därför finns det inget problem med hönan och ägget, som det var med Auto-RP.
3) Så snart RP får ett meddelande från BSR-router, skickar den omedelbart ett unicast-meddelande till BSR-router-adressen:

Därefter, när BSR har fått information om RP, skickar den ut dem som multicast till adress 224.0.0.13, som alla PIM-routrar lyssnar på. Därför finns det ingen motsvarighet till kommandot ip pim autorp listener för vanliga routrar i BSR.
Anycast RP med Multicast Source Discovery Protocol (MSDP).
Auto-RP och BSR gör att vi kan fördela belastningen på RP på följande sätt: Varje multicast-grupp har endast en aktiv RP. Det går inte att fördela belastningen för en multicast-grupp till flera RP. MSDP gör detta genom att ge RP-routrarna samma IP-adress med mask 255.255.255.255. MSDP får information via en av metoderna: statik, Auto-RP eller BSR.

På bilden har vi en Auto-RP-konfiguration med MSDP. Båda RP är inställda med IP-adressen 172.16.1.1/32 på Loopback 1-gränssnittet och används för alla grupper. Vid RP-Announce berättar båda routrarna om sig själva och refererar till denna adress. Auto-RP mapping agent, som får information, sprider RP-Discovery om RP med adressen 172.16.1.1/32. Om nätverket 172.16.1.1/32 informerar vi routrarna genom IGP. På så sätt begär eller registrerar PIM-routrarna flöden från den RP som anges som next-hop i routen till nätverket 172.16.1.1/32. Själva MSDP-protokollet är avsett för RP:erna, så de kan utbyta meddelanden om information om multicast.
Låt oss överväga en sådan topologi:

Switch6 sänder trafik till adress 238.38.38.38 och känner bara till detta RP-R1. Här har Switch7 och Switch8 begärt denna grupp. Routrarna R5 och R4 kommer att skicka PIM Join till R1 respektive R3. Varför? Rutt till 13.13.13.13 hos R5 kommer att hänvisa till R1 baserat på IGP-metriken, precis som hos R4.
RP-R1 känner till flödet och börjar sända det mot R5, men R4 vet inget om det, eftersom R1 inte kommer att skicka det utan anledning. Därför behövs MSDP. 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 skapa en session mellan varandra och vid mottagande av något flöde kommer de att informera sin RP-granne om det.
RP-R1 kommer så snart den får flödet från Switch6 att skicka ett unicast MSDP Source-Active meddelande som innehåller information av typen (S, G) — information om källan och destinationen för multicast. Nu, när RP-R3 vet att det finns en källa som Switch6, kommer den vid mottagande av en förfrågan från R4 om detta flöde att skicka en PIM Join mot Switch6, baserat på routingtabeln. Därmed, när R1 får en sådan PIM Join, kommer den att börja skicka trafik mot RP-R3.
MSDP fungerar över TCP, RP skickar keepalive-meddelanden till varandra för att kontrollera livability. Timern är 60 sekunder.
Funktionen för att dela MSDP peer i olika domäner förblir oklar, eftersom keepalive-meddelanden och SA inte anger tillhörighet till någon domän. I denna topologi testades också konfigurationen med olika domäner — det var ingen skillnad i prestanda.
Om någon kan klargöra detta, skulle jag gärna läsa i kommentarerna.

Källa: habr.com