PIM-protokollen er en rĂŠkke protokoller til overfĂžrsel af multicast i netvĂŠrk mellem routere. Naboskaberne opbygges ligesom ved dynamiske routingprotokoller. PIMv2 sender hvert 30. sekund Hello-beskeder til den reserverede multicast-adresse 224.0.0.13 (All-PIM-Routers). Beskeden indeholder Hold Timers â normalt lig med 3.5*Hello Timer, hvilket betyder 105 sekunder som standard.
PIM har to hoveddriftsformer â Dense og Sparse mode. Lad os begynde med Dense mode.
Source-Based Distribution Trees.
Dense-mode er hensigtsmÊssigt at anvende i tilfÊlde af et stort antal klienter i forskellige multicast-grupper. NÄr en router modtager multicast-trafik, kontrollerer den fÞrst trafikreglen RPF. RPF-reglen bruges til at kontrollere kilde for multicast med den unicast routingtabel. Det er nÞdvendigt, at trafikken kommer ind pÄ den interface, som den pÄgÊldende vÊrt er skjult bag ifÞlge unicast routingtabellen. Denne mekanisme lÞser problemet med loop-dannelse ved overfÞrsel af multicast.
R3 finder ud af kilden til multicast (Source IP) gennem multicast-beskeden og kontrollerer to strÞmme fra R1 og R2 i sin unicast routingtabel. StrÞmmen fra den interface, som routingtabellen peger pÄ (R1 til R3), vil blive sendt videre, mens strÞmmen fra R2 vil blive droppet, da det skal sende pakker gennem S0/1 for at nÄ kildemiljÞet.
Hvad hvis du har to Êkvivalente ruter med samme metrik? I dette tilfÊlde vil routeren vÊlge baseret pÄ next-hop for de pÄgÊldende ruter. Den med den hÞjeste IP-adresse vinder. Hvis det er nÞdvendigt at Êndre denne adfÊrd, kan man bruge ECMP. LÊs mere. .
Efter kontrol af RPF-reglen sender routeren multicast-pakken til alle sine PIM-naboer, undtagen den, som pakken blev modtaget fra. De andre PIM-routiere gentager denne proces. Stien, som multicast-pakken har taget fra kilden til de endelige modtagere, danner et trĂŠ, der kaldes â source-based distribution tree, shortest-path tree (SPT), source tree. Tre forskellige navne, vĂŠlg et.
Hvordan lÞser man spÞrgsmÄlet om, at nogle routere ikke har brug for en bestemt multicast-strÞm, og der ikke er nogen til at sende den, men den overordnede router sender den? Til dette er Prune-mekanismen opfundet.
Prune Message.
For eksempel vil R2 fortsÊtte med at sende multicast til R3, selvom R3 afviser det i henhold til RPF-reglen. Hvorfor belaste kanalen? R3 sender en PIM Prune-besked, og R2, nÄr den modtager denne besked, fjerner interface S0/1 fra listen over udgÄende interfaces for denne strÞm, listen over interfaces, som skal sende denne trafik.
FĂžlgende er en mere formel definition af en PIM Prune-besked:
PIM Prune-beskeden sendes af én router til en anden router for at fÄ den anden router til at fjerne den forbindelse, hvorpÄ Prune modtages fra et bestemt (S,G) SPT.
Efter modtagelsen af Prune-beskeden sĂŠtter R2 Prune-timeren til 3 minutter. Efter tre minutter vil den begynde at sende trafik igen, indtil den modtager endnu en Prune-besked. Dette gĂŠlder i PIMv1.
I PIMv2 er der tilfÞjet en State Refresh-timer (som standard 60 sekunder). SÄ snart der er sendt en Prune-besked fra R3, startes denne timer pÄ R3. NÄr timeren udlÞber, vil R3 sende en State Refresh-besked, der nulstiller R2's 3-minutters Prune-timer for denne gruppe.
Ă
rsager til at sende en Prune-besked:
- NĂ„r multicast-pakken ikke bestod RPF-kontrollen.
- NĂ„r der ikke er lokalt tilsluttede klienter, der har anmodet om den multicast-gruppe (IGMP Join), og der ikke er PIM-naboer, som multicast-trafik kan sendes til (Non-prune Interface).
Graft Message.
Lad os forestille os, at R3 ikke ville have trafik fra R2, sendte Prune og modtog multicast fra R1. Men pludselig gik forbindelsen mellem R1-R3 ned, og R3 er uden multicast. Man kan vente 3 minutter, indtil R2's Prune-timer udlÞber. At vente 3 minutter er lÊnge, for ikke at skulle vente, er det nÞdvendigt at sende en besked, der Þjeblikkeligt vil fjerne dette interface S0/1 pÄ R2 fra det pruned-tilstand. En sÄdan besked vil vÊre Graft-beskeden. Efter modtagelsen af Graft-beskeden vil R2 sende en Graft-ACK som svar.
Prune Override.
Lad os se pĂ„ denne ordning. R1 sender multicast til en segment med to routere. R3 modtager og sender trafik, R2 modtager, men der er ingen at sende trafik til. Han sender en Prune-besked til R1 i dette segment. R1 skal fjerne Fa0/0 fra listen og stoppe med at sende til dette segment, men hvad med R3? R3 befinder sig i den samme segment, har ogsĂ„ modtaget denne Prune-besked og forstĂ„r hele alvoren i situationen. FĂžr R1 stopper med at sende, sĂŠtter han en timer pĂ„ 3 sekunder og stopper med at sende efter 3 sekunder. 3 sekunder â det er prĂŠcis den tid, R3 har til ikke at miste sin multicast. Derfor sender R3 sĂ„ hurtigt som muligt en Pim Join-besked for denne gruppe, og R1 overvejer ikke lĂŠngere at stoppe med at sende. Om Join-beskederne nedenfor.
Assert-besked.
Forestil dig en situation, hvor to routere sender i Ă©t netvĂŠrk. De modtager den samme strĂžm fra kilden, og begge sender den til et netvĂŠrk via interface e0. Derfor skal de afgĂžre, hvem der bliver den eneste afsender for dette netvĂŠrk. Det gĂžres ved hjĂŠlp af Assert-beskeder. NĂ„r R2 og R3 opdager duplikation af multicast-trafik, det vil sige, at multicast, som de selv sender, ogsĂ„ modtages pĂ„ R2 og R3, forstĂ„r routerne, at der er noget galt. I dette tilfĂŠlde sender routerne Assert-beskeder, som inkluderer Administrative Distance og metrikken for ruten til kilden til multicast â 10.1.1.10. Vinderne bestemmes sĂ„ledes:
- Den med lavest AD.
- Hvis AD er lige, sÄ den med lavest metrik.
- Hvis der stadig er ligestilling, sÄ den med den hÞjeste IP i det netvÊrk, de sender denne multicast til.
Den der vinder denne afstemning, bliver Designated Router. Til valg af DR bruges ogsÄ Pim Hello. I begyndelsen af artiklen blev et PIM Hello-besked vist, hvor man kan se DR-feltet. Den med de hÞjeste IP-adresser pÄ denne forbindelse vinder.
Nyttigt skema:
MROUTE-tabel.
Efter den indledende gennemgang af, hvordan PIM-protokollen fungerer, er det nÞdvendigt at forstÄ, hvordan man arbejder med multicast-routingtabellen. I mroute-tabellen opbevares information om, hvilke streams der er blevet anmodet af kunderne, og hvilke streams der strÞmmer fra multicast-serverne.
For eksempel, ved modtagelse af IGMP Membership Report eller PIM Join pÄ et interface, tilfÞjes der en post af typen ( *, G ) til routingtabellen:
Denne post betyder, at der er modtaget en anmodning om trafik fra adressen 238.38.38.38. DC-flaget betyder, at multicast vil fungere i Dense mode, og C betyder, at modtageren er direkte tilsluttet routeren, det vil sige, at routeren har modtaget en IGMP Membership Report, samt PIM Join.
Hvis der er en post af typen (S,G), betyder det, at vi har en multicast-strĂžm:
I feltet S â 192.168.1.11, har vi angivet IP-adressen for kilden til multicast, som vil blive kontrolleret af RPF-reglen. Hvis der er problemer, skal du fĂžrst tjekke unicast-tabellen for ruten til kilden. I Incoming Interface angives det interface, hvor multicast'en modtages. I unicast-routingtabellen skal ruten til kilden pege pĂ„ det interface, der er angivet her. I Outgoing Interface angives, hvor multicast'en vil blive videresendt. Hvis det er tomt, betyder det, at routeren ikke har modtaget anmodninger om denne trafik. Du kan finde mere detaljerede oplysninger om alle flagene .
PIM Sparse-mode.
Sparse-mode-strategien er modsat Dense-mode. NĂ„r Sparse-mode modtager multicast-trafik, vil den sende trafikken kun gennem de interfaces, hvor der har vĂŠret anmodninger om denne strĂžm, for eksempel Pim Join eller IGMP Report-meddelelser med anmodning om denne trafik.
Lignende elementer i SM og DM:
- Naboskaber etableres ogsÄ som i PIM DM.
- RPF-reglen gĂŠlder.
- Valget af DR er det samme.
- Prune Overrides-mekanismen og Assert-beskederne er analoge.
For at kontrollere, hvem, hvor, og hvilken multicast-trafik der er brug for i netvĂŠrket, er der behov for et fĂŠlles informationscentrum. Dette centrum bliver vores Rendezvous Point (RP). Alle, der Ăžnsker en bestemt multicast-trafik eller som er begyndt at modtage multicast-trafik fra kilden, sender det til RP.
NĂ„r RP modtager multicast-trafikken, sender den 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 det denne multicast-pakke i en unicast PIM Register-besked og sender den til RP. Hvordan ved den, hvem RP er? I dette tilfĂŠlde er den statisk konfigureret, og vi vil tale om dynamisk konfiguration af RP senere.
ip pim rp-address 3.3.3.3
RP vil undersÞge, om der var information fra nogen, der Þnskede at modtage denne trafik? Lad os antage, at der ikke var nogen. SÄ sender RP et Register-Stop-besked til R1, hvilket betyder, at ingen Þnsker denne multicast, registreringen er afvist. R1 vil ikke sende multicast. Men kilden til multicast vil fortsat sende den, sÄ R1, efter at have modtaget Register-Stop, vil starte en Register-Suppression-timer pÄ 60 sekunder. 5 sekunder fÞr denne timer udlÞber, vil R1 sende en tom Register-besked med Null-Register-bit (dvs. uden indkapslet multicast-pakke) mod RP. RP vil pÄ sin side handle sÄledes:
- Hvis der ikke var nogen modtagere, vil han svare med en Register-Stop-besked.
- Hvis der er opstÄet modtagere, vil han ikke svare pÄ den. R1, der ikke har modtaget afvisning pÄ sin registrering inden for 5 sekunder, vil vÊre glad og sende en Register-besked med indkapslet multicast til RP.
Vi har forhÄbentlig klaret, hvordan multicast nÄr frem til RP; nu vil vi forsÞge at besvare spÞrgsmÄlet om, hvordan RP leverer trafikken til modtagerne. Her er det nÞdvendigt at introducere et nyt begreb - root-path tree (RPT). RPT er et trÊ med rod i RP, der vokser mod modtagerne og forgrener sig ved hver PIM-SM-router. RP skaber det ved at modtage PIM Join-beskeder og tilfÞjer en ny gren til trÊet. Og sÄdan gÞr hver underliggende router. Den overordnede regel ser sÄledes ud:
- NÄr en PIM-SM-router modtager en PIM Join-besked pÄ en hvilken som helst interface, undtagen den interface, hvor RP er skjult, tilfÞjer den en ny gren til trÊet.
- En gren tilfÞjes ogsÄ, nÄr en PIM-SM-router modtager en IGMP Membership Report fra en direkte tilsluttet vÊrt.
Lad os forestille os, at vi har en multicast-klient pĂ„ router R5 til gruppe 228.8.8.8. SĂ„ snart R5 modtager en IGMP Membership Report fra vĂŠrten, sender R5 en PIM Join mod RP og tilfĂžjer selv interfacet, der peger mod vĂŠrten, til trĂŠet. Derefter modtager R4 PIM Join fra R5, tilfĂžjer interfacet Gi0/1 til trĂŠet og sender PIM Join mod RP. Endelig modtager RP (R3) PIM Join og tilfĂžjer Gi0/0 til trĂŠet. PĂ„ denne mĂ„de gĂžr vi modtagerregistreringen af multicast. Vi bygger et trĂŠ med roden R3-Gi0/0 â R4-Gi0/1 â R5-Gi0/0.
Efter dette vil PIM Join blive sendt til R1, og R1 vil begynde at sende multicast trafik. Det er vigtigt at bemÊrke, at hvis vÊrten anmoder om trafik, fÞr multicast-afsendelsen er begyndt, sÄ vil RP ikke sende PIM Join og overhovedet ikke sende noget til R1.
Hvis vÊrten pludselig stopper med at ville modtage multicast, sÄ snart RP modtager PIM Prune pÄ interface Gi0/0, vil den straks sende PIM Register-Stop direkte til R1, og derefter PIM Prune meddelelse via interface Gi0/1. PIM Register-Stop sendes unicast til den adresse, hvorfra PIM Register blev modtaget.
Som vi nÊvnte tidligere, sÄ snart routeren sender PIM Join til en anden, for eksempel R5 til R4, sÄ bliver der tilfÞjet en post pÄ R4:
Og der startes en timer, som R5 konstant skal resettere ved at sende PIM Join meddelelser, ellers vil R4 udelukke den fra outgoing list. R5 vil sende PIM Join meddelelser hver 60. gang.
Shortest-Path Tree Switchover.
Vi vil tilfĂžje et interface mellem R1 og R5, og se hvordan trafikken vil flyde i denne topologi.
Lad os antage, at trafikken blev sendt og modtaget efter den gamle ordning R1-R2-R3-R4-R5, og nu har vi tilsluttet og konfigureret et interface mellem R1 og R5.
For det fĂžrste vil unicast routing tabellen pĂ„ R5 blive ombygget, og nu nĂ„s netvĂŠrket 192.168.1.0/24 gennem interface R5 Gi0/2. Nu, nĂ„r R5 modtager multicast pĂ„ interface Gi0/1, forstĂ„r den, at RPF-reglen ikke er opfyldt, og det ville vĂŠre mere logisk at modtage multicast pĂ„ Gi0/2. Den skal frakoble sig fra RPT og opbygge et kortere trĂŠ, der kaldes Shortest-Path Tree (SPT). For dette sender den via Gi0/2 PIM Join til R1, og R1 begynder ogsĂ„ at sende multicast gennem Gi0/2. Nu skal R5 afmelde sig fra RPT for ikke at modtage to kopier. For dette sender den en Prune meddelelse angivende IP-adressen pĂ„ kilden og indsĂŠtter et specielt bit â RPT-bit. Det betyder, at jeg ikke Ăžnsker trafik sendt til mig, da jeg har et bedre trĂŠ her. RP sender ogsĂ„ PIM Prune meddelelser mod R1, men sender ikke Register-Stop meddelelser. En anden funktion: R5 vil nu konstant sende PIM Prune til RP, da R1 fortsĂŠtter med at sende PIM Register til RP hvert minut. RP vil, indtil der er nye interesserede i denne trafik, svare ham med afslag. R5 informerer RP om, at den fortsat modtager multicast gennem SPT.
Dynamisk sĂžgning af RP.
Auto-RP.
Denne teknologi er proprietĂŠr fra Cisco og er ikke sĂŠrlig populĂŠr, men den er stadigvĂŠk i brug. Auto-RP arbejder i to hovedfaser:
1) RP sender RP-Announce beskeder til den reserverede adresse â 224.0.1.39, og erklĂŠrer sig selv som RP enten for alle eller for specifikke grupper. Denne besked sendes hvert minut.
2) En RP mapping agent er nÞdvendig, som sender RP-Discovery beskeder med angivelse af, hvilke grupper der skal lytte til hvilken RP. Det er fra denne besked, almindelige PIM-routere vil bestemme deres RP. Mapping agenten kan vÊre enten den samme RP-router eller en separat PIM-router. RP-Discovery sendes til adressen 224.0.1.40 med et interval pÄ et minut.
Lad os se nÊrmere pÄ processen:
Indstil 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
Og vi vil forvente RP via Auto-RP pÄ alle de andre:
ip pim autorp listener
SĂ„ snart vi indstiller R3, vil den begynde at sende RP-Announce:
Og R2, efter at vÊre blevet indstillet som mapping agent, vil begynde at vente pÄ RP-Announce beskeder. Kun nÄr den finder mindst én RP, vil den begynde at sende RP-Discovery:
PÄ den mÄde, nÄr almindelige routere (PIM RP Listener) modtager disse beskeder, ved de, hvor de skal lede efter RP.
Et af hovedproblemerne med Auto-RP er, at for at modtage RP-Announce og RP-Discovery beskeder skal der sendes PIM Join til adresserne 224.0.1.39-40, og for at sende, skal man vide, hvor RP'en befinder sig. Det klassiske problem med kylling og Êg. For at lÞse dette problem blev PIM Sparse-Dense-Mode opfundet. Hvis routeren ikke kender RP, arbejder den i Dense-mode, hvis den gÞr, sÄ i Sparse-mode. NÄr PIM Sparse-mode er indstillet pÄ de almindelige routeres interfaces og kommandoen ip pim autorp listener er aktiveret, vil routeren fungere i Dense-mode kun for multicast af selve Auto-RP protokollen (224.0.1.39-40).
BootStrap Router (BSR).
Denne funktion fungerer pÄ en mÄde som Auto-RP. Hver RP sender en besked til mapping agenten, som indsamler mapping information og fortÊller derefter alle de andre routere. Lad os beskrive processen pÄ samme mÄde som Auto-RP:
1) SĂ„ snart vi indstiller R3 som kandidat til at vĂŠre RP, med kommandoen:
ip pim rp-candidate loopback 0
Vil R3 ikke gÞre noget, for at begynde at sende specielle beskeder, skal den fÞrst finde mapping agenten. Derfor gÄr vi videre til det andet trin.
2) Indstil R2 som mapping agent:
ip pim bsr-kandidat loopback 0
R2 begynder at sende PIM Bootstrap beskeder, hvor den angiver sig selv som mapping agent:
Denne besked sendes til adressen 224.0.0.13, som PIM-protokollen ogsÄ bruger til sine andre beskeder. Den sender dem i alle retninger, sÄ der er ikke noget problem med hÞnen og Êgget, som med Auto-RP.
3) SĂ„ snart RP modtager beskeden fra BSR-routeren, sender den straks en unicast-besked til adressen BSR-routeren:
Derefter vil BSR, efter at have modtaget informationen om RP, sende dem multicast til adressen 224.0.0.13, som alle PIM-routere lytter til. Derfor er der ikke et modstykke til kommandoen ip pim autorp listener for almindelige routere i BSR.
Anycast RP med Multicast Source Discovery Protocol (MSDP).
Auto-RP og BSR gÞr det muligt for os at fordele belastningen pÄ RP som fÞlger: Hver multicast-gruppe har kun én aktiv RP. Det er ikke muligt at fordele belastningen for en enkelt multicast-gruppe pÄ flere RP'er. MSDP gÞr dette ved at tildele RP-routerne den samme ip-adresse med masken 255.255.255.255. MSDP fÄr 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-adressen 172.16.1.1/32 pÄ Loopback 1-interfacet og bruges til alle grupper. Ved RP-announce fortÊller begge routere om sig selv, med henvisning til denne adresse. Auto-RP mapping agent, der modtager information, sender RP-Discovery om RP med adressen 172.16.1.1/32. Om netvÊrket 172.16.1.1/32 fortÊller vi routerne ved hjÊlp af IGP, og tilsvarende. Dermed anmoder PIM-routerne om eller registrerer strÞmme fra den RP, der er angivet som next-hop til ruten til netvÊrket 172.16.1.1/32. Selve MSDP-protokollen er designet til RP'er, sÄ de kan udveksle beskeder om information om multicast.
Lad os overveje denne topologi:
Switch6 broadcaster trafik til adressen 238.38.38.38, og indtil videre kender kun RP-R1 til den. Nu har Switch7 og Switch8 anmodet om denne gruppe. Routerne R5 og R4 vil sende PIM Join til R1 og R3, henholdsvis. Hvorfor? Ruten til 13.13.13.13 hos R5 vil henvise til R1 efter IGP-metrik, ligesom hos R4.
RP-R1 kender til strÞmmen og begynder at sende den mod R5, men R4 ved intet om den, da R1 ikke vil sende den bare sÄdan. 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 etablere en session mellem hinanden, og ved modtagelse af en hvilken som helst strĂžm vil de informere om den til deres RP-nabo.
NÄr RP-R1 modtager strÞm fra Switch6, sender den straks en unicast MSDP Source-Active meddelelse, som indeholder informationstype (S, G) - oplysninger om kilde og destination for multicast. Nu, nÄr RP-R3 ved, at der er en kilde som Switch6, vil den ved modtagelse af en anmodning fra R4 om denne strÞm sende en PIM Join mod Switch6 baseret pÄ routing-tabellen. Derfor vil R1, nÄr den modtager denne PIM Join, begynde at sende trafik i retning af RP-R3.
MSDP fungerer over TCP, RP sender keepalive beskeder til hinanden for at kontrollere deres livskraft. Timeren er 60 sekunder.
Funktionen til at opdele MSDP-naboer i forskellige domÊner forbliver uklar, da der i Keepalive og SA-beskederne ikke angives tilhÞrsforhold til noget domÊne. I denne topologi blev der ogsÄ testet en konfiguration med angivelse af forskellige domÊner - der var ingen forskel i driften.
Hvis nogen kan bringe klarhed, vil jeg med glĂŠde lĂŠse kommentarer.
Kilde: habr.com
