PIM-protokollen er et sæt protokoller til transmission af multicast i et netværk mellem routere. Naboskabsrelationer bygges på samme måde som i tilfældet med dynamiske routingprotokoller. PIMv2 sender Hello-beskeder hvert 30. sekund til den reserverede multicast-adresse 224.0.0.13 (All-PIM-routere). Beskeden indeholder Hold Timers - normalt lig med 3.5*Hej Timer, det vil sige 105 sekunder som standard.
PIM bruger to hoveddriftstilstande - Tæt og sparsom tilstand. Lad os starte med tæt tilstand.
Kildebaserede distributionstræer.
Dense-mode-tilstand anbefales at bruge i tilfælde af et stort antal klienter fra forskellige multicast-grupper. Når en router modtager multicast-trafik, er den første ting, den gør, at tjekke den for RPF-reglen. RPF - denne regel bruges til at kontrollere kilden til en multicast med en unicast-routingtabel. Det er nødvendigt, at trafikken ankommer til grænsefladen, bag hvilken denne vært er skjult i henhold til versionen af unicast-routingtabellen. Denne mekanisme løser problemet med en sløjfe, der opstår under multicast-transmission.
R3 vil genkende multicast-kilden (kilde-IP) fra multicast-meddelelsen og kontrollere de to flows fra R1 og R2 ved hjælp af dens unicast-tabel. Strømmen fra grænsefladen, som tabellen peger på (R1 til R3), vil blive transmitteret videre, og strømmen fra R2 vil blive droppet, da du for at komme til multicast-kilden skal sende pakker via S0/1.
Spørgsmålet er, hvad der sker, hvis du har to ækvivalente ruter med samme metrik? I dette tilfælde vil routeren vælge det næste hop fra disse ruter. Den, der har den højeste IP-adresse, vinder. Hvis du har brug for at ændre denne adfærd, kan du bruge ECMP. Flere detaljer .
Efter at have kontrolleret RPF-reglen, sender routeren en multicast-pakke til alle sine PIM-naboer, undtagen den, som pakken blev modtaget fra. Andre PIM-routere gentager denne proces. Stien, som en multicast-pakke har taget fra kilden til de endelige modtagere, danner et træ kaldet kildebaseret distributionstræ, shortest-path tree (SPT), kildetræ. Tre forskellige navne, vælg et.
Hvordan man løser problemet med, at nogle routere ikke gav op på en eller anden multicast-stream, og der er ingen at sende den til, men upstream-routeren sender den til ham. Sveskemekanismen blev opfundet til dette.
Beskær besked.
For eksempel vil R2 fortsætte med at sende en multicast til R3, selvom R3 ifølge RPF-reglen dropper den. Hvorfor indlæse kanalen? R3 sender en PIM Prune-besked, og R2 vil ved modtagelse af denne besked fjerne grænseflade S0/1 fra den udgående grænsefladeliste for dette flow, listen over grænseflader, hvorfra denne trafik skal sendes.
Følgende er en mere formel definition af en PIM Prune-meddelelse:
PIM Prune-meddelelsen sendes af en router til en anden router for at få den anden router til at fjerne linket, hvorpå Prune modtages fra en bestemt (S,G) SPT.
Efter at have modtaget beskæringsmeddelelsen, indstiller R2 beskæringstimeren til 3 minutter. Efter tre minutter begynder den at sende trafik igen, indtil den modtager endnu en Prune-meddelelse. Dette er i PIMv1.
Og i PIMv2 er der tilføjet en tilstandsopdateringstimer (60 sekunder som standard). Så snart der er sendt en prune-meddelelse fra R3, startes denne timer på R3. Når denne timer er udløbet, sender R3 en tilstandsopdateringsmeddelelse, som vil nulstille 3-minutters beskæringstimeren på R2 for denne gruppe.
Årsager til at sende en sveskebesked:
- Når en multicast-pakke mislykkes i RPF-kontrollen.
- Når der ikke er nogen lokalt tilsluttede klienter, der har anmodet om en multicast-gruppe (IGMP Join), og der ikke er nogen PIM-naboer, som multicast-trafik kan sendes til (Non-prune Interface).
Podemeddelelse.
Lad os forestille os, at R3 ikke ønskede trafik fra R2, sendte Prune og modtog en multicast fra R1. Men pludselig faldt kanalen mellem R1-R3, og R3 stod uden multicast. Du kan vente 3 minutter, indtil beskæringstimeren på R2 udløber. 3 minutter er lang ventetid, for ikke at vente, skal du sende en besked, der øjeblikkeligt bringer denne S0/1-grænseflade til R2 ud af den beskærede tilstand. Denne besked vil være en graft-meddelelse. Efter at have modtaget graft-meddelelsen, vil R2 svare med en graft-ACK.
Beskær tilsidesættelse.
Lad os se på dette diagram. R1 udsender multicast til et segment med to routere. R3 modtager og sender trafik, R2 modtager, men har ingen at sende trafik til. Den sender en prune besked til R1 i dette segment. R1 burde fjerne Fa0/0 fra listen og stoppe med at udsende i dette segment, men hvad vil der ske med R3? Og R3 er i samme segment, modtog også denne besked fra Prune og forstod tragedien i situationen. Før R1 stopper udsendelsen, indstiller den en timer på 3 sekunder og stopper med at sende efter 3 sekunder. 3 sekunder - det er præcis hvor meget tid R3 har for ikke at miste sin multicast. Derfor sender R3 hurtigst muligt en Pim Join besked til denne gruppe, og R1 tænker ikke længere på at stoppe udsendelsen. Om Deltag beskeder nedenfor.
Påstå besked.
Lad os forestille os denne situation: to routere sender til ét netværk på én gang. De modtager den samme stream fra kilden, og sender den begge til det samme netværk bag grænsefladen e0. Derfor er de nødt til at afgøre, hvem der vil være den eneste udsender for dette netværk. Påstandsmeddelelser bruges til dette. Når R2 og R3 registrerer duplikering af multicast-trafik, det vil sige, at der ankommer en multicast til R2 og R3, som de selv udsender, forstår routerne, at der er noget galt her. I dette tilfælde sender routere Assert-meddelelser, som inkluderer Administrativ afstand og rutemetrikken, som multicast-kilden nås med - 10.1.1.10. Vinderen bestemmes som følger:
- Den med lavere AD.
- Hvis AD er ens, hvem har så den laveste metrik.
- Hvis der er ligestilling her, så er den, der har den højere IP i det netværk, som de sender denne multicast til.
Vinderen af denne afstemning bliver Designated Router. Pim Hello bruges også til at vælge DR'er. I begyndelsen af artiklen blev PIM Hej beskeden vist, du kan se DR feltet der. Den med den højeste IP-adresse på dette link vinder.
Nyttigt tegn:
MROUTE tabel.
Efter et indledende kig på, hvordan PIM-protokollen fungerer, skal vi forstå, hvordan man arbejder med en multicast-routingtabel. Mroute-tabellen gemmer information om, hvilke streams der blev anmodet om fra klienter, og hvilke streams der flyder fra multicast-servere.
For eksempel, når en IGMP-medlemsrapport eller PIM-tilmelding modtages på en eller anden grænseflade, tilføjes en post af typen (*, G) til routingtabellen:
Denne indtastning betyder, at der blev modtaget en trafikanmodning med adressen 238.38.38.38. DC-flaget betyder, at multicasten vil fungere i tæt tilstand, og C betyder, at modtageren er direkte forbundet til routeren, det vil sige, at routeren modtog IGMP Membership Report og PIM Join.
Hvis der er en registrering af typen (S,G), betyder det, at vi har en multicast-stream:
I S-feltet - 192.168.1.11, har vi registreret IP-adressen på multicast-kilden, det er denne, der vil blive kontrolleret af RPF-reglen. Hvis der er problemer, er den første ting, du skal gøre, at tjekke unicast-tabellen for ruten til kilden. I feltet Indgående grænseflade angiver grænsefladen, som multicasten modtages til. I en unicast-routingtabel skal ruten til kilden referere til den grænseflade, der er angivet her. Den udgående grænseflade angiver, hvor multicasten vil blive omdirigeret. Hvis den er tom, har routeren ikke modtaget nogen anmodninger om denne trafik. Mere information om alle flag kan findes .
PIM Sparse-tilstand.
Strategien i Sparse-mode er det modsatte af tæt-mode. Når Sparse-mode modtager multicast-trafik, vil den kun sende trafik gennem de grænseflader, hvor der var anmodninger om dette flow, for eksempel Pim Join eller IGMP Report-meddelelser, der anmoder om denne trafik.
Lignende elementer for SM og DM:
- Naboforhold bygges på samme måde som i PIM DM.
- RPF-reglen virker.
- DR-udvalget ligner.
- Mekanismen for Prune Overrides og Assert-meddelelser ligner hinanden.
For at kontrollere, hvem, hvor og hvilken slags multicast-trafik der er behov for på netværket, er der behov for et fælles informationscenter. Vores center vil være Rendezvous Point (RP). Enhver, der ønsker en form for multicast-trafik, eller nogen er begyndt at modtage multicast-trafik fra kilden, så sender han den til RP.
Når RP'en modtager multicast-trafik, vil den sende den til de routere, der tidligere har anmodet om denne trafik.
Lad os forestille os en topologi, hvor RP er R3. Så snart R1 modtager trafik fra S1, indkapsler den denne multicast-pakke i en unicast PIM Register-meddelelse og sender den til RP. Hvordan ved han, hvem RP er? I dette tilfælde er det konfigureret statisk, og vi vil tale om dynamisk RP-konfiguration senere.
ip pim rp-adresse 3.3.3.3
RP vil kigge - var der oplysninger fra nogen, der gerne vil modtage denne trafik? Lad os antage, at det ikke var det. Så vil RP sende R1 en PIM Register-Stop besked, hvilket betyder at ingen har brug for denne multicast, registrering nægtes. R1 sender ikke multicast. Men multicast-kildeværten vil sende det, så R1, efter at have modtaget Register-Stop, vil starte en Register-Suppression-timer svarende til 60 sekunder. 5 sekunder før denne timer udløber, vil R1 sende en tom Register-meddelelse med en Null-Register-bit (det vil sige uden en indkapslet multicast-pakke) mod RP. RP vil til gengæld agere sådan:
- Hvis der ikke var nogen modtagere, vil den svare med en Register-Stop-meddelelse.
- Hvis der dukker modtagere op, vil han ikke reagere på det på nogen måde. R1, der ikke har modtaget et afslag på registrering inden for 5 sekunder, vil være glad og sende en Register-meddelelse med en indkapslet multicast til RP.
Vi ser ud til at have fundet ud af, hvordan multicast når RP, lad os nu prøve at besvare spørgsmålet om, hvordan RP leverer trafik til modtagere. Her er det nødvendigt at introducere et nyt koncept - root-path tree (RPT). RPT er et træ med rod i RP, der vokser mod modtagerne og forgrener sig på hver PIM-SM-router. RP opretter det ved at modtage PIM Join-beskeder og tilføjer en ny gren til træet. Og det gør hver downstream-router. Den generelle regel ser således ud:
- Når en PIM-SM-router modtager en PIM Join-meddelelse på en hvilken som helst anden grænseflade end den grænseflade, som RP'en er skjult bag, tilføjer den en ny gren til træet.
- En filial tilføjes også, når PIM-SM-routeren modtager en IGMP-medlemsrapport fra en direkte tilsluttet vært.
Lad os forestille os, at vi har en multicast-klient på R5-routeren til gruppe 228.8.8.8. Så snart R5 modtager IGMP-medlemsrapporten fra værten, sender R5 en PIM Join i retning af RP og tilføjer selv en grænseflade til træet, der ser på værten. Dernæst modtager R4 PIM Join fra R5, tilføjer interface Gi0/1 til træet og sender PIM Join i retning af RP. Til sidst modtager RP ( R3 ) PIM Join og tilføjer Gi0/0 til træet. Dermed er multicast-modtageren registreret. Vi bygger et træ med roden R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Herefter vil en PIM Join blive sendt til R1 og R1 vil begynde at sende multicast trafik. Det er vigtigt at bemærke, at hvis værten anmodede om trafik, før multicast-udsendelsen begyndte, så sender RP ikke PIM Join og sender slet ikke noget til R1.
Hvis værten pludselig holder op med at ville modtage den, mens en multicast sendes, så snart RP modtager en PIM Prune på Gi0/0-grænsefladen, vil den straks sende et PIM Register-Stop direkte til R1 og derefter en PIM Prune besked via Gi0/1-grænsefladen. PIM Register-stop sendes via unicast til den adresse, hvorfra PIM Registeret kom.
Som vi sagde tidligere, så snart en router sender en PIM Join til en anden, for eksempel R5 til R4, tilføjes en post til R4:
Og der startes en timer, som R5 konstant skal nulstille denne timer PIM Join beskeder konstant, ellers vil R4 blive udelukket fra den udgående liste. R5 sender hver 60 PIM Join beskeder.
Træskifte på korteste vej.
Vi vil tilføje en grænseflade mellem R1 og R5 og se, hvordan trafikken flyder med denne topologi.
Lad os antage, at trafik blev sendt og modtaget i henhold til det gamle skema R1-R2-R3-R4-R5, og her har vi forbundet og konfigureret grænsefladen mellem R1 og R5.
Først og fremmest skal vi genopbygge unicast-routingtabellen på R5, og nu nås netværket 192.168.1.0/24 gennem R5 Gi0/2-grænsefladen. Nu forstår R5, der modtager multicast på grænsefladen Gi0/1, at RPF-reglen ikke er opfyldt, og det ville være mere logisk at modtage multicast på Gi0/2. Det bør afbryde forbindelsen til RPT og bygge et kortere træ kaldet Shortest-Path Tree (SPT). For at gøre dette sender han PIM Join til R0 gennem Gi2/1, og R1 begynder at sende en multicast også gennem Gi0/2. Nu skal R5 afmelde RPT for ikke at modtage to kopier. For at gøre dette sender han Prune en besked, der angiver kildens IP-adresse og indsætter en speciel bit - RPT-bit. Det betyder, at du ikke behøver at sende mig trafik, jeg har et bedre træ her. RP sender også PIM Prune beskeder til R1, men sender ikke en Register-Stop besked. En anden funktion: R5 vil nu løbende sende PIM Prune til RP, da R1 fortsætter med at sende PIM Register til RP hvert minut. Indtil der ikke er nye mennesker, der ønsker denne trafik, vil RP afvise det. R5 meddeler RP, at den fortsætter med at modtage multicast via SPT.
Dynamisk RP-søgning.
Auto-RP.
Denne teknologi er proprietær fra Cisco og er ikke særlig populær, men er stadig i live. Auto-RP-drift består af to hovedtrin:
1) RP sender RP-Announce beskeder til den reserverede adresse - 224.0.1.39, og erklærer sig RP enten for alle eller for specifikke grupper. Denne besked sendes hvert minut.
2) Der kræves en RP-mapping-agent, som sender RP-Discovery-meddelelser, der angiver, for hvilke grupper, hvilken RP skal lyttes til. Det er ud fra denne besked, at almindelige PIM-routere selv bestemmer RP. Mapping Agent kan enten være selve RP-routeren eller en separat PIM-router. RP-Discovery sendes til adresse 224.0.1.40 med en timer på et minut.
Lad os se på processen mere detaljeret:
Lad os konfigurere R3 som RP:
ip pim send-rp-announce loopback 0 scope 10
R2 som kortlægningsmiddel:
ip pim send-rp-discovery loopback 0 scope 10
Og på alle andre vil vi forvente RP via Auto-RP:
ip pim autorp lytter
Når vi har konfigureret R3, begynder den at sende RP-Announce:
Og R2, efter opsætning af kortlægningsagenten, begynder at vente på RP-Announce-meddelelsen. Først når den finder mindst én RP, begynder den at sende RP-Discovery:
På denne måde, så snart almindelige routere (PIM RP Listener) modtager denne besked, vil de vide, hvor de skal lede efter RP.
Et af hovedproblemerne med Auto-RP er, at for at modtage RP-Announce og RP-Discovery beskeder, skal du sende PIM Join til adresserne 224.0.1.39-40, og for at kunne sende, skal du vide, hvor RP er placeret. Klassisk kylling og æg problem. For at løse dette problem blev PIM Sparse-Dense-Mode opfundet. Hvis routeren ikke kender RP, så fungerer den i tæt-tilstand; hvis den gør, så i sparse-tilstand. Når PIM Sparse-mode og ip pim autorp listener-kommandoen er konfigureret på grænseflader på almindelige routere, vil routeren kun fungere i tæt-mode til multicasting direkte fra Auto-RP-protokollen (224.0.1.39-40).
BootStrap Router (BSR).
Denne funktion fungerer på samme måde som Auto-RP. Hver RP sender en besked til kortlægningsagenten, som indsamler kortoplysninger og derefter fortæller alle andre routere. Lad os beskrive processen på samme måde som Auto-RP:
1) Når vi konfigurerer R3 som en kandidat til at være RP, med kommandoen:
ip pim rp-kandidat loopback 0
Så vil R3 ikke gøre noget; for at begynde at sende specielle beskeder skal han først finde en kortlægningsagent. Dermed går vi videre til andet trin.
2) Konfigurer R2 som en kortlægningsagent:
ip pim bsr-kandidat loopback 0
R2 begynder at sende PIM Bootstrap-beskeder, hvor den angiver sig selv som en kortlægningsagent:
Denne besked sendes til adressen 224.0.013, som PIM-protokollen også bruger til sine andre beskeder. Det sender dem i alle retninger, og derfor er der ikke noget hønse- og ægproblem, som der var i Auto-RP.
3) Så snart RP modtager en besked fra BSR-routeren, sender den straks en unicast-meddelelse til BSR-routeradressen:
Hvorefter BSR'en, efter at have modtaget information om RP'erne, sender dem med multicast til adressen 224.0.0.13, som lyttes til af alle PIM-routere. Derfor en analog af kommandoen ip pim autorp lytter til almindelige routere ikke i BSR.
Anycast RP med Multicast Source Discovery Protocol (MSDP).
Auto-RP og BSR giver os mulighed for at fordele belastningen på RP som følger: Hver multicast-gruppe har kun én aktiv RP. Det vil ikke være muligt at fordele belastningen for én multicast-gruppe over flere RP'er. MSDP gør dette ved at udstede RP-routere den samme IP-adresse med en maske på 255.255.255.255. MSDP lærer information ved hjælp af en af metoderne: statisk, Auto-RP eller BSR.
På billedet har vi en Auto-RP konfiguration med MSDP. Begge RP'er er konfigureret med IP-adresse 172.16.1.1/32 på Loopback 1-interface og bruges til alle grupper. Med RP-Announce annoncerer begge routere sig selv ved at henvise til denne adresse. Auto-RP-kortlægningsagenten sender, efter at have modtaget oplysningerne, RP-Discovery om RP'en med adressen 172.16.1.1/32. Vi fortæller routere om netværket 172.16.1.1/32 ved hjælp af IGP og i overensstemmelse hermed. Således anmoder eller registrerer PIM-routere strømme fra den RP, der er angivet som næste hop på ruten til netværket 172.16.1.1/32. Selve MSDP-protokollen er designet til, at RP'erne selv kan udveksle meddelelser om multicast-information.
Overvej denne topologi:
Switch6 sender trafik til adressen 238.38.38.38 og indtil videre er det kun RP-R1, der kender til det. Switch7 og Switch8 anmodede om denne gruppe. Routere R5 og R4 sender PIM Join til henholdsvis R1 og R3. Hvorfor? Ruten til 13.13.13.13 for R5 vil referere til R1 ved hjælp af IGP-metrikken, ligesom for R4.
RP-R1 kender til streamen og vil begynde at udsende den mod R5, men R4 ved ikke noget om den, da R1 ikke bare sender den. Derfor er MSDP nødvendigt. Vi konfigurerer det på R1 og 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 vil rejse en session mellem hinanden, og når de modtager et flow, vil de rapportere det til deres RP-nabo.
Så snart RP-R1 modtager en stream fra Switch6, vil den straks sende en unicast MSDP Source-Active besked, som vil indeholde information som (S, G) - information om kilden og destinationen for multicasten. Nu hvor RP-R3 ved, at en kilde som Switch6, når den modtager en anmodning fra R4 om dette flow, vil sende PIM Join mod Switch6, styret af routingtabellen. Som følge heraf vil R1, der har modtaget en sådan PIM Join, begynde at sende trafik mod RP-R3.
MSDP kører over TCP, RP'er sender hinanden live-beskeder for at kontrollere livlighed. Timeren er 60 sekunder.
Funktionen med at opdele MSDP-peers i forskellige domæner er stadig uklar, da Keepalive- og SA-meddelelser ikke angiver medlemskab i noget domæne. I denne topologi testede vi også en konfiguration, der indikerer forskellige domæner - der var ingen forskel i ydeevne.
Hvis nogen kan præcisere, vil jeg med glæde læse det i kommentarerne.
Kilde: www.habr.com