Protocolul PIM este un set de protocoale pentru transmiterea multicast-ului în rețea între routere. Relațiile de vecinătate sunt stabilite în mod similar cu cele ale protocoalelor de rutare dinamice. PIMv2 trimite mesaje Hello la fiecare 30 de secunde pe adresa multicast rezervată 224.0.0.13 (All-PIM-Routers). Mesajul conține Timerele Hold — de obicei, acestea sunt egale cu 3,5 * Hello Timer, adică 105 secunde în mod implicit.
PIM utilizează două moduri principale de operare — Dense și Sparse mode. Să începem cu Dense mode.
Arbori de Distribuție Bazati pe Sursă.
Modul Dense este recomandat a fi folosit în cazul unui număr mare de clienți din diverse grupuri multicast. Atunci când routerul primește trafic multicast, acesta verifică mai întâi regula RPF. RPF — această regulă este utilizată pentru a verifica sursa multicast-ului cu tabela de rutare unicast. Traficul trebuie să sosească pe interfața pe care se află acest host conform tabelei de rutare unicast. Acest mecanism rezolvă problema apariției buclelor în timpul transmiterii multicast-ului.
R3 din mesajul multicast află sursa multicast-ului (Source IP) și va verifica cele două fluxuri de la R1 și R2 conform tabelei sale de rutare unicast. Fluxul de pe interfața indicată de tabelă (R1 către R3) va fi transmis mai departe, iar fluxul de la R2 va fi eliminat, deoarece, pentru a ajunge la sursa multicast-ului, trebuie trimise pachete prin S0/1.
Întrebarea este: ce se întâmplă dacă aveți două rute echivalente cu aceeași metrică? În acest caz, routerul va alege în funcție de next-hop între aceste rute. Cel cu adresa IP mai mare va câștiga. Dacă este necesar să schimbați acest comportament, puteți utiliza ECMP. Mai multe detalii. .
După verificarea regulii RPF, routerul trimite pachetul multicast tuturor vecinilor săi PIM, cu excepția celui de la care a fost primit acest pachet. Celelalte routere PIM repetă acest proces. Drumul parcurs de pachetul multicast de la sursă la destinatarii finali formează un arbore, numit — arbore de distribuție bazat pe sursă, arbore de drumuri scurte (SPT), arbore de sursă. Trei denumiri diferite, alegeți orice.
Cum să rezolvăm problema că unor routere nu le-a fost transmis un anumit flux multicast și nu au pe cine să-l trimită, dar routerul superior le trimite? Pentru aceasta a fost inventat mecanismul Prune.
Prune Message.
De exemplu, R2 va continua să trimită multicast către R3, deși R3 îl elimină conform regulii RPF. De ce să suprasolicităm canalul? R3 trimite un mesaj PIM Prune, iar R2, la primirea acestui mesaj, va elimina interfața S0/1 din lista de interfețe (outgoing interface list) pentru acest flux, lista interfețelor de la care trebuie trimis acest trafic.
Următoarea este o definiție mai formală a unui mesaj PIM Prune:
Mesajul PIM Prune este trimis de un router unui alt router pentru a determina al doilea router să elimine legătura pe care a fost primit Prune dintr-un anumit SPT (S,G).
La primirea mesajului Prune, R2 setează un timer Prune de 3 minute. După trei minute va începe să trimită din nou trafic, până nu primește un alt mesaj Prune. Aceasta este în PIMv1.
În PIMv2 a fost adăugat un timer State Refresh (în mod implicit 60 de secunde). De îndată ce a fost trimis un mesaj Prune de la R3, acest timer se activează pe R3. La expirarea acestui timer, R3 va trimite un mesaj State Refresh, care va reseta timerul Prune de 3 minute pe R2 pentru acest grup.
Motivele trimiterii unui mesaj Prune:
- Când pachetul multicast nu a trecut verificarea RPF.
- Când nu există clienți conectați local care să fi solicitat grupul multicast (IGMP Join) și nu sunt vecini PIM cărora să le poată trimite trafic multicast (Non-prune Interface).
Mesaj Graft.
Să presupunem că R3 nu a dorit trafic de la R2, a trimis Prune și a primit multicast de la R1. Dar dintr-o dată, canalul între R1-R3 a căzut, iar R3 a rămas fără multicast. Se poate aștepta 3 minute, până când timerul Prune de pe R2 expiră. 3 minute este mult, pentru a nu aștepta, este necesar să se trimită un mesaj care să scoată instantaneu această interfață S0/1 de pe R2 din starea pruned. Un astfel de mesaj va fi mesajul Graft. După primirea mesajului Graft, R2 va trimite înapoi Graft-ACK.
Prune Override.
Să analizăm acest scenariu. R1 transmite multicast într-un segment cu două routere. R3 primește și transmite traficul, R2 primește, dar nu are pe cine să transmită. El trimite un mesaj Prune către R1 în acest segment. R1 trebuie să elimine Fa0/0 din listă și să înceteze să transmită în acest segment, dar ce se va întâmpla cu R3? R3 se află în același segment și a primit și el acest mesaj Prune, înțelegând gravitatea situației. Înainte ca R1 să înceteze să transmită, el setează un temporizator de 3 secunde și va înceta transmisia după 3 secunde. 3 secunde — exact atât timp are R3 pentru a nu pierde multicast-ul său. De aceea, R3 trimite cât mai repede un mesaj Pim Join pentru acest grup și R1 nu mai consideră să înceteze transmisia. Despre mesajele Join mai jos.
Mesaj Assert.
Să ne imaginăm o situație: în aceeași rețea transmit simultan două routere. Ele primesc același flux de la sursă și ambele îl transmit într-o singură rețea prin interfața e0. Prin urmare, trebuie săDetermine cine va fi singurul emitent pentru această rețea. Pentru aceasta se folosesc mesajele Assert. Atunci când R2 și R3 detectează duplicarea traficului multicast, adică atât pe R2 cât și pe R3 ajunge multicast-ul pe care ele îl transmit, routerele înțeleg că ceva nu este în regulă. Routerele în acest caz trimit mesaje Assert, care includ Distanta Administrației și metrica rutei prin care se ajunge la sursa multicast-ului — 10.1.1.10. Câștigătorul se determină astfel:
- Cel cu AD mai mic.
- Dacă AD-urile sunt egale, atunci cel cu metrica mai mică.
- Dacă și aici există egalitate, atunci cel cu IP-ul mai mare în rețeaua în care transmit acest multicast.
Câștigătorul acestei votări devine Routerul Designat. Pentru a alege DR se folosesc de asemenea Pim Hello. La începutul articolului a fost prezentat mesajul PIM Hello, unde se poate observa câmpul DR. Câștigă cel cu adresa IP mai mare pe acest link.
O tabelă utilă:
Tabel MROUTE.
După analiza inițială a funcționării protocolului PIM, trebuie să înțelegem cum să lucrăm cu tabela de rutare multicast. În tabela mroute se stochează informații despre ce fluxuri au fost solicitate de clienți și ce fluxuri sunt transmise de serverele multicast.
De exemplu, la primirea unui IGMP Membership Report sau PIM Join pe o interfață, se adaugă o înregistrare de tip (*, G) în tabela de rutare:
Această înregistrare semnifică faptul că a fost primit o cerere de trafic de la adresa 238.38.38.38. Flacul DC indică faptul că multicast-ul va funcționa în modul Dense mode, iar C înseamnă că destinatarul este direct conectat la router, adică routerul a primit IGMP Membership Report și PIM Join.
Dacă există o înregistrare de tip (S,G), aceasta înseamnă că avem un flux multicast:
În câmpul S — 192.168.1.11, avem adresa IP a sursei multicast; aceasta va fi verificată de regula RPF. În caz de probleme, primul lucru de verificat este tabela unicast pentru ruta către sursă. În câmpul Incoming Interface se specifică interfața pe care ajunge multicast-ul. În tabela de rutare unicast, ruta către sursă trebuie să facă referire la interfața specificată aici. În Outgoing Interface se specifică unde va fi redirecționat multicast-ul. Dacă este gol, înseamnă că către router nu au fost trimise cereri pentru acest trafic. Informații mai detaliate despre toate flagurile pot fi găsite .
PIM Sparse-mode.
Strategia Sparse-mode este opusă Dense-mode. Când Sparse-mode primește trafic multicast, va trimite traficul doar prin acele interfețe unde au fost cereri pentru acest flux, de exemplu mesaje Pim Join sau IGMP Report cu cererea pentru acest trafic.
Elementele similare între SM și DM:
- Relațiile de vecinătate sunt stabilite la fel ca în PIM DM.
- Regula RPF funcționează.
- Alegerea DR este similară.
- Mecanismul Prune Overrides și mesajele Assert sunt similare.
Pentru a controla cine, unde și ce trafic multicast este necesar în rețea, este nevoie de un centru informațional comun. Acest centru va fi Rendezvous Point (RP). Toți cei care doresc trafic multicast sau cei care au început să primească trafic multicast de la sursă, trimite cererea la RP.
Când RP primește trafic multicast, va trimite către acei routeri care au solicitat anterior acest trafic.
Să ne imaginăm o topologie în care RP este R3. De îndată ce R1 primește trafic de la S1, acesta va încapsula pachetul multicast în mesajul unicast PIM Register și îl va trimite la RP. De unde știe cine este RP? În acest caz, este configurat static, iar despre configurarea dinamică a RP vom discuta mai târziu.
ip pim rp-address 3.3.3.3
RP se va uita - a existat informația de la cineva care ar dori să primească acest trafic? Presupunem că nu a fost. Atunci, RP va trimite un mesaj R1 PIM Register-Stop, ceea ce înseamnă - nimănui nu-i trebuie acest multicast, înregistrarea este refuzată. R1 nu va trimite multicast. Dar sursa host-ului multicast va continua să-l trimită, așa că R1, după ce primește Register-Stop, va porni un temporizator Register-Suppression, setat pe 60 de secunde. Cu 5 secunde înainte de expirarea acestui temporizator, R1 va trimite un mesaj Register gol cu bitul Null-Register (adică fără pachetul multicast încapsulat) către RP. RP, la rândul său, va acționa astfel:
- Dacă nu au existat destinatari, el va răspunde cu un mesaj Register-Stop.
- Dacă au apărut destinatari, el nu va răspunde deloc. R1, nesemnalandu-se refuzul pe înregistrare în termen de 5 secunde, se va bucura și va trimite un mesaj Register cu multicast încapsulat către RP.
Cum ajunge multicastul la RP pare că s-a lămurit, acum să încercăm să răspundem la întrebarea cum RP aduce traficul la destinatari. Aici trebuie introdus un nou concept - arborele root-path (RPT). RPT - este un arbore cu rădăcina în RP, crescând spre destinatari, ramificându-se la fiecare router PIM-SM. RP îl creează, primind mesaje PIM Join și adaugă o nouă ramură în arbore. Astfel, fiecare router inferior face la fel. Regula generală este următoarea:
- Când un router PIM-SM primește un mesaj PIM Join pe orice interfață, cu excepția interfeței care ascunde RP, el adaugă o nouă ramură în arbore.
- De asemenea, o ramură se adaugă atunci când un router PIM-SM primește un raport de apartenență IGMP de la un host conectat direct.
Să ne imaginăm că avem un client multicast pe routerul R5 pe grupul 228.8.8.8. De îndată ce R5 primește un raport de apartenență IGMP de la host, R5 trimite PIM Join către RP și adaugă interfața care vede către host în arbore. Apoi, R4 primește PIM Join de la R5, adaugă interfața Gi0/1 în arbore și trimite PIM Join către RP. În final, RP (R3) primește PIM Join și adaugă Gi0/0 în arbore. Astfel, se obține înregistrarea destinatarului multicast. Se construiește un arbore cu rădăcina R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
După aceasta, PIM Join va fi trimis către R1 și R1 va începe să trimită trafic multicast. Este important de menționat că, dacă hostul a solicitat trafic înainte de a începe difuzarea multicast-ului, RP nu va trimite PIM Join și, în general, nu va trimite nimic către R1.
Dacă, în timp ce se trimite multicast, hostul nu mai dorește să-l primească, de îndată ce RP primește PIM Prune pe interfața Gi0/0, va trimite imediat PIM Register-Stop direct către R1, iar apoi un mesaj PIM Prune prin interfața Gi0/1. PIM Register-stop este trimis unicast către adresa de pe care a venit PIM Register.
Așa cum am menționat anterior, de îndată ce routerul trimite PIM Join altuia, de exemplu R5 către R4, o înregistrare este adăugată pe R4:
Și se activează un temporizator, ceea ce înseamnă că R5 trebuie să trimită constant mesaje PIM Join, altfel R4 va exclude lista de ieșire. R5 va trimite mesaje PIM Join la fiecare 60 de secunde.
Schimbarea arborelui de cea mai scurtă cale.
Vom adăuga o interfață între R1 și R5, să vedem cum va curge traficul cu această topologie.
Să presupunem că traficul a fost trimis și primit conform vechii scheme R1-R2-R3-R4-R5 și acum am conectat și configurat interfața între R1 și R5.
În primul rând, tabela de rutare unicast de pe R5 se va reconstrui și acum rețeaua 192.168.1.0/24 este accesibilă prin interfața R5 Gi0/2. Acum, R5 primind multicast pe interfața Gi0/1, înțelege că regula RPF nu este satisfăcută și ar fi mai logic să primească multicast pe Gi0/2. El trebuie să se deconecteze de la RPT și să construiască un arbore mai scurt, numit Shortest-Path Tree (SPT). Pentru aceasta trimite PIM Join pe R1 prin Gi0/2, iar R1 începe să trimită multicast și prin Gi0/2. Acum, R5 trebuie să se dezaboneze de la RPT pentru a nu primi două copii. Pentru aceasta, trimite un mesaj Prune specificând adresa IP a sursei și adăugând un bit special — RPT-bit. Acest lucru înseamnă că nu trebuie să-mi trimiți trafic, am aici un arbore mai bun. RP trimite de asemenea mesaje PIM Prune către R1, dar nu trimite mesajul Register-Stop. O altă caracteristică: R5 va trimite constant PIM Prune către RP, deoarece R1 continuă să trimită PIM Register către RP în fiecare minut. RP, până nu vor exista noi doritori pentru acest trafic, îi va răspunde cu un refuz. R5 notifică RP că continuă să primească multicast prin SPT.
Căutarea dinamică RP.
Auto-RP.
Această tehnologie este proprietară Cisco și nu este foarte populară, dar încă există. Funcționarea Auto-RP constă în două etape principale:
1) RP trimite mesaje RP-Announce la adresa rezervată — 224.0.1.39, anunțându-se ca RP fie pentru toate grupurile, fie pentru anumite grupuri. Acest mesaj este trimis la fiecare minut.
2) Este necesar un agent de mapare RP, care va trimite mesaje RP-Discovery indicând pentru ce grupuri trebuie să asculte fiecare RP. Din acest mesaj, routerele PIM obișnuite își vor determina RP-ul. Agentul de mapare poate fi fie routerul RP însuși, fie un alt router PIM separat. RP-Discovery este trimis la adresa 224.0.1.40 cu un timer de un minut.
Să discutăm procesul în detaliu:
Configurați R3 ca RP:
ip pim send-rp-announce loopback 0 scope 10
R2 ca agent de mapare:
ip pim send-rp-discovery loopback 0 scope 10
Iar pe toate celelalte vom aștepta RP prin Auto-RP:
ip pim autorp listener
Odată ce configurăm R3, acesta va începe să trimită RP-Announce:
După ce R2 este configurat ca agent de mapare, acesta va începe să aștepte mesajele RP-Announce. Numai când găsește cel puțin un RP, va începe să trimită RP-Discovery:
Astfel, de îndată ce routerele obișnuite ( PIM RP Listener ) primesc acest mesaj, ele vor ști unde să caute RP.
Una dintre principalele probleme ale Auto-RP este că pentru a primi mesajele RP-Announce și RP-Discovery este necesar să se trimită PIM Join la adresele 224.0.1.39-40, iar pentru a trimite, trebuie să știm unde se află RP. Este o problemă clasică de tipul găinii și oului. Pentru a rezolva această problemă, a fost inventat modul PIM Sparse-Dense-Mode. Dacă routerul nu știe de RP, atunci funcționează în modul Dense-mode, iar dacă știe, atunci în modul Sparse-mode. Când pe interfețele routerelor obișnuite este configurat PIM Sparse-mode și comanda ip pim autorp listener, routerul va funcționa în modul Dense-mode doar pentru multicastul protocolului Auto-RP ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Această funcție funcționează similar cu Auto-RP. Fiecare RP trimite un mesaj agentului de mapare, care adună informațiile de mapare și apoi le comunică tuturor celorlalte routere. Să descriem procesul similar cu Auto-RP:
1) De îndată ce configurăm R3 ca fiind candidatul pentru a fi RP, prin comandă:
ip pim rp-candidate loopback 0
Atunci R3 nu va face nimic, pentru a începe să trimită mesaje speciale, trebuie mai întâi să găsească agentul de mapare. Astfel, trecem la pasul doi.
2) Configurăm R2 ca agent de mapare:
ip pim bsr-candidate loopback 0
R2 începe să trimită mesaje PIM Bootstrap, în care se indică pe sine ca agent de mapping:
Acest mesaj este trimis la adresa 224.0.0.13, pe care protocolul PIM o folosește și pentru alte mesaje. Acesta le trimite în toate direcțiile, astfel că nu există problema oului și a puiului, așa cum era la Auto-RP.
3) De îndată ce RP primește un mesaj de la routerul BSR, acesta va trimite imediat un mesaj unicast la adresa routerului BSR:
După aceea, BSR, primind informațiile despre RP, le va trimite prin multicast la adresa 224.0.0.13, pe care o ascultă toate routerele PIM. Prin urmare, nu există un echivalent pentru comanda ip pim autorp listener pentru routerele obișnuite în BSR.
Anycast RP cu Protocolul de Descoperire a Sursei Multicast (MSDP).
Auto-RP și BSR ne permit să distribuită sarcina pe RP în următorul mod: Fiecare grup multicast are un singur RP activ. Nu se poate realiza o distribuție a sarcinii pentru un grup multicast cu mai multe RP-uri. MSDP face acest lucru prin atribuirea routerelor RP a aceleași adrese IP cu masca 255.255.255.255. MSDP află informații prin una dintre metode: statică, Auto-RP sau BSR.
În imagine avem o configurație Auto-RP cu MSDP. Ambele RP-uri sunt configurate cu adresa IP 172.16.1.1/32 pe interfața Loopback 1 și este folosită pentru toate grupurile. La RP-Announce, ambele routere se anunță reciproc, referindu-se la această adresă. Agentul de mapping Auto-RP, primind informațiile, trimite RP-Discovery despre RP cu adresa 172.16.1.1/32. Despre rețeaua 172.16.1.1/32, informăm routerele prin IGP și, în consecință. Astfel, routerele PIM solicită sau se înregistrează pentru fluxuri de la RP-ul care este indicat ca next-hop în ruta către rețeaua 172.16.1.1/32. Protocolul MSDP este destinat RP-urilor pentru a schimba mesaje despre informațiile multicast.
Să analizăm o astfel de topologie:
Switch6 transmite trafic la adresa 238.38.38.38 și deocamdată doar RP-R1 știe acest lucru. Switch7 și Switch8 au solicitat acest grup. Routerele R5 și R4 vor trimite PIM Join la R1 și R3, respectiv. De ce? Ruta către 13.13.13.13 la R5 va face referire la R1 prin metrica IGP, la fel ca și la R4.
RP-R1 știe despre flux și va începe să-l transmită către R5, însă R4 nu știe nimic despre el, deoarece R1 nu îl va trimite pur și simplu. De aceea, MSDP este necesar. Îl configurăm pe R1 și R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 pe R1
ip msdp peer 1.1.1.1 connect-source Loopback3 pe R3
Acestea vor stabili o sesiune între ele și, atunci când primesc un flux, vor anunța RP-ul vecin despre acesta.
RP-R1 va trimite imediat un mesaj MSDP Source-Active prin unicast atunci când va primi fluxul de la Switch6, care va conține informații de tip (S, G) – informații despre sursă și destinația multicast. Acum, când RP-R3 va ști că există o sursă precum Switch6, la primirea unei cereri de la R4 pentru acest flux, va trimite PIM Join către Switch6, conform tabelului de rutare. Prin urmare, R1, primind acest PIM Join, va începe să trimită traficul către RP-R3.
MSDP funcționează pe TCP, RP-uri își trimit unul altuia mesaje keepalive pentru a verifica viabilitatea. Timerul este de 60 de secunde.
Funcția de separare a piroanelor MSDP în domenii diferite rămâne neclară, deoarece în mesajele Keepalive și SA nu se specifică apartenența la vreun domeniu. De asemenea, în această topologie s-a testat o configurație cu specificarea diferitelor domenii – nu au fost observate diferențe în funcționare.
Dacă cineva poate aduce lămuriri, aș fi bucuros să citesc în comentarii.
Sursa: habr.com
