Protocolul PIM este un set de protocoale pentru transmiterea multicast într-o rețea între routere. Relațiile de vecinătate sunt construite în același mod ca și în cazul protocoalelor de rutare dinamică. PIMv2 trimite mesaje Hello la fiecare 30 de secunde către adresa multicast rezervată 224.0.0.13 (All-PIM-Routers). Mesajul conține cronometre de așteptare - de obicei egal cu 3.5*Hello Timer, adică 105 secunde în mod implicit.
PIM utilizează două moduri principale de operare - modul Dens și Scarse. Să începem cu modul Dens.
Arbori de distribuție bazați pe sursă.
Modul în mod dens este recomandabil să fie utilizat în cazul unui număr mare de clienți din diferite grupuri multicast. Când un router primește trafic multicast, primul lucru pe care îl face este să îl verifice pentru regula RPF. RPF - această regulă este folosită pentru a verifica sursa unui multicast cu un tabel de rutare unicast. Este necesar ca traficul să ajungă la interfața în spatele căreia este ascunsă această gazdă în funcție de versiunea tabelului de rutare unicast. Acest mecanism rezolvă problema unei bucle care apare în timpul transmisiei multicast.
R3 va recunoaște sursa multicast (IP sursă) din mesajul multicast și va verifica cele două fluxuri de la R1 și R2 folosind tabelul său unicast. Fluxul de la interfața indicată de tabel (R1 la R3) va fi transmis în continuare, iar fluxul de la R2 va fi abandonat, deoarece pentru a ajunge la sursa multicast, trebuie să trimiteți 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 selecta următorul hop din aceste rute. Câștigă cine are adresa IP mai mare. Dacă trebuie să modificați acest comportament, puteți utiliza ECMP. Mai multe detalii .
După verificarea regulii RPF, routerul trimite un pachet multicast către toți vecinii săi PIM, cu excepția celui de la care a fost primit pachetul. Alte routere PIM repetă acest proces. Calea pe care un pachet multicast a luat-o de la sursă la destinatarii finali formează un arbore numit arbore de distribuție bazat pe sursă, arbore cu calea cea mai scurtă (SPT), arbore sursă. Trei nume diferite, alegeți oricare.
Cum se rezolvă problema că unele routere nu au renunțat la un stream multicast și nu există cui să-l trimită, dar routerul din amonte îi trimite. Mecanismul Prune a fost inventat pentru asta.
Prune Message.
De exemplu, R2 va continua să trimită un multicast către R3, deși R3, conform regulii RPF, îl renunță. De ce încărcați canalul? R3 trimite un PIM Prune Message iar R2, la primirea acestui mesaj, va elimina interfața S0/1 din lista de interfețe de ieșire pentru acest flux, lista de interfețe de la care ar trebui trimis acest trafic.
Următoarea este o definiție mai formală a unui mesaj PIM Prune:
Mesajul PIM Prune este trimis de un router către un al doilea router pentru ca cel de-al doilea router să elimine legătura pe care este primit Prune de la un anumit (S,G) SPT.
După primirea mesajului Prune, R2 setează cronometrul Prune la 3 minute. După trei minute, va începe să trimită din nou trafic până când va primi un alt mesaj Prune. Acesta este în PIMv1.
Și în PIMv2 a fost adăugat un cronometru de reîmprospătare a stării (60 de secunde în mod implicit). De îndată ce un mesaj Prune a fost trimis de la R3, acest temporizator este pornit pe R3. La expirarea acestui temporizator, R3 va trimite un mesaj de actualizare a stării, care va reseta cronometrul de tăiere de 3 minute pe R2 pentru acest grup.
Motive pentru trimiterea unui mesaj Prune:
- Când un pachet multicast eșuează verificarea RPF.
- Când nu există clienți conectați la nivel local care au solicitat un grup multicast (IGMP Join) și nu există vecini PIM către care să poată fi trimis trafic multicast (Interfață non-prune).
Mesaj de grefa.
Să ne imaginăm că R3 nu a vrut trafic de la R2, a trimis Prune și a primit un multicast de la R1. Dar brusc, canalul dintre R1-R3 a căzut și R3 a rămas fără multicast. Puteți aștepta 3 minute până când Timer-ul de tăiere pe R2 expiră. 3 minute este o așteptare lungă, pentru a nu aștepta, trebuie să trimiteți un mesaj care va scoate instantaneu această interfață S0/1 la R2 din starea tăiată. Acest mesaj va fi un mesaj Graft. După primirea mesajului Graft, R2 va răspunde cu un Graft-ACK.
Override Prune.
Să ne uităm la această diagramă. R1 transmite multicast către un segment cu două routere. R3 primește și difuzează trafic, R2 primește, dar nu are cui să transmită trafic. Trimite un mesaj Prune către R1 în acest segment. R1 ar trebui să elimine Fa0/0 din listă și să oprească difuzarea în acest segment, dar ce se va întâmpla cu R3? Și R3 este în același segment, a primit și acest mesaj de la Prune și a înțeles tragedia situației. Înainte ca R1 să oprească difuzarea, setează un temporizator de 3 secunde și va opri difuzarea după 3 secunde. 3 secunde - exact acesta este cât timp are R3 pentru a nu-și pierde multicastul. Prin urmare, R3 trimite un mesaj Pim Join pentru acest grup cât mai curând posibil, iar R1 nu se mai gândește să oprească difuzarea. Despre Alăturați-vă mesajelor de mai jos.
Afirmați mesajul.
Să ne imaginăm această situație: două routere difuzează la o singură rețea deodată. Ei primesc același flux de la sursă și ambii îl transmit către aceeași rețea din spatele interfeței e0. Prin urmare, trebuie să stabilească cine va fi singurul radiodifuzor pentru această rețea. Mesajele de afirmare sunt folosite pentru aceasta. Când R2 și R3 detectează duplicarea traficului multicast, adică R2 și R3 primesc un multicast pe care ei înșiși îl transmit, routerele înțeleg că ceva nu este în regulă aici. În acest caz, routerele trimit mesaje Assert, care includ Distanța administrativă și metrica rutei cu care este atinsă sursa multicast - 10.1.1.10. Câștigătorul este stabilit după cum urmează:
- Cel cu AD inferioară.
- Dacă AD sunt egale, atunci cine are metrica mai mică.
- Dacă aici este egalitate, atunci cel care are IP-ul mai mare în rețeaua către care difuzează acest multicast.
Câștigătorul acestui vot devine Routerul Desemnat. Pim Hello este, de asemenea, folosit pentru a selecta DR. La începutul articolului, a fost afișat mesajul PIM Hello, puteți vedea câmpul DR acolo. Câștigă cel cu cea mai mare adresă IP pe acest link.
Semn util:
MROUTE Tabel.
După o privire inițială asupra modului în care funcționează protocolul PIM, trebuie să înțelegem cum să lucrăm cu un tabel de rutare multicast. Tabelul mroute stochează informații despre ce fluxuri au fost solicitate de la clienți și care fluxuri circulă de la serverele multicast.
De exemplu, atunci când se primește un raport de membru IGMP sau o alăturare PIM pe o anumită interfață, o înregistrare de tip ( *, G ) este adăugată la tabelul de rutare:
Această intrare înseamnă că a fost primită o solicitare de trafic cu adresa 238.38.38.38. Indicatorul DC înseamnă că multicastul va funcționa în modul Dens și C înseamnă că destinatarul este conectat direct la router, adică routerul a primit Raportul de membru IGMP și PIM Join.
Dacă există o înregistrare de tip (S,G) înseamnă că avem un flux multicast:
În câmpul S - 192.168.1.11, am înregistrat adresa IP a sursei multicast, aceasta este cea care va fi verificată de regula RPF. Dacă există probleme, primul lucru pe care trebuie să-l faceți este să verificați tabelul unicast pentru ruta către sursă. În câmpul Interfață de intrare, indică interfața către care este recepționat multicast. Într-un tabel de rutare unicast, ruta către sursă trebuie să se refere la interfața specificată aici. Interfața de ieșire specifică unde va fi redirecționat multicastul. Dacă este gol, atunci routerul nu a primit nicio solicitare pentru acest trafic. Mai multe informații despre toate steagurile pot fi găsite .
PIM Scarse-mode.
Strategia modului rar este opusă modului dens. Atunci când modul Sparse primește trafic multicast, va trimite trafic numai prin acele interfețe în care au existat solicitări pentru acest flux, de exemplu mesaje Pim Join sau IGMP Report care solicită acest trafic.
Elemente similare pentru SM și DM:
- Relațiile de vecinătate sunt construite în același mod ca în PIM DM.
- Regula FPR funcționează.
- Selecția DR este similară.
- Mecanismul mesajelor Prune Overrides și Assert sunt similare.
Pentru a controla cine, unde și ce fel de trafic multicast este necesar în rețea, este nevoie de un centru de informare comun. Centrul nostru va fi Rendezvous Point (RP). Oricine dorește un fel de trafic multicast sau cineva a început să primească trafic multicast de la sursă, apoi îl trimite la RP.
Când RP-ul primește trafic multicast, îl va trimite acelor routere 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, încapsulează acest pachet multicast într-un mesaj unicast PIM Register și îl trimite către RP. De unde știe cine este RP-ul? În acest caz, este configurat static, iar despre configurația RP dinamică vom vorbi mai târziu.
ip pim rp-adresa 3.3.3.3
RP va căuta - au existat informații de la cineva care ar dori să primească acest trafic? Să presupunem că nu a fost. Apoi RP va trimite lui R1 un mesaj PIM Register-Stop, ceea ce înseamnă că nimeni nu are nevoie de acest multicast, înregistrarea este refuzată. R1 nu va trimite multicast. Dar gazda sursă multicast o va trimite, astfel încât R1, după primirea Register-Stop, va porni un temporizator Register-Suppression egal cu 60 de secunde. Cu 5 secunde înainte de expirarea acestui temporizator, R1 va trimite un mesaj de înregistrare gol cu un bit Null-Register (adică fără un pachet multicast încapsulat) către RP. RP, la rândul său, va acționa astfel:
- Dacă nu au existat destinatari, atunci va răspunde cu un mesaj Register-Stop.
- Dacă apar destinatari, el nu va răspunde în niciun fel. R1, care nu a primit un refuz de a se înregistra în 5 secunde, va fi fericit și va trimite un mesaj Register cu o multicast încapsulată către RP.
Se pare că ne-am dat seama cum multicast ajunge la RP, acum să încercăm să răspundem la întrebarea cum RP livrează trafic destinatarilor. Aici este necesar să se introducă un nou concept - root-path tree (RPT). RPT este un arbore înrădăcinat în RP, care crește către destinatari, ramificându-se pe fiecare router PIM-SM. RP îl creează primind mesaje PIM Join și adaugă o nouă ramură în arbore. Și așa, orice router din aval o face. Regula generală arată astfel:
- Când un router PIM-SM primește un mesaj PIM Join pe orice interfață, alta decât interfața în spatele căreia este ascuns RP, acesta adaugă o nouă ramură în arbore.
- O ramură este, de asemenea, adăugată atunci când routerul PIM-SM primește un raport de membru IGMP de la o gazdă conectată direct.
Să ne imaginăm că avem un client multicast pe routerul R5 pentru grupul 228.8.8.8. De îndată ce R5 primește Raportul de membru IGMP de la gazdă, R5 trimite un PIM Join în direcția RP și adaugă el însuși o interfață la arborele care se uită la gazdă. Apoi, R4 primește PIM Join de la R5, adaugă interfața Gi0/1 la arbore și trimite PIM Join în direcția RP. În cele din urmă, RP (R3) primește PIM Join și adaugă Gi0/0 în arbore. Astfel, destinatarul multicast este înregistrat. Construim un arbore cu rădăcina R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
După aceasta, un PIM Join va fi trimis către R1 și R1 va începe să trimită trafic multicast. Este important de reținut că, dacă gazda a solicitat trafic înainte de a începe difuzarea multicast, atunci RP nu va trimite PIM Join și nu va trimite nimic către R1 deloc.
Dacă brusc, în timpul trimiterii unui multicast, gazda nu mai vrea să-l primească, de îndată ce RP primește un PIM Prune pe interfața Gi0/0, va trimite imediat un PIM Register-Stop direct către R1 și apoi un PIM Prune mesaj prin interfața Gi0/1. PIM Register-stop este trimis prin unicast la adresa de la care provine PIM Register.
După cum am spus mai devreme, de îndată ce un router trimite un PIM Join către altul, de exemplu R5 la R4, atunci o înregistrare este adăugată la R4:
Și este pornit un temporizator pe care R5 trebuie să resetați constant acest temporizator PIM Join mesajele în mod constant, altfel R4 va fi exclus din lista de ieșire. R5 va trimite la fiecare 60 de mesaje PIM Join.
Comutarea arborelui pe calea cea mai scurtă.
Vom adăuga o interfață între R1 și R5 și vom vedea cum circulă traficul cu această topologie.
Să presupunem că traficul a fost trimis și primit conform vechii scheme R1-R2-R3-R4-R5, iar aici am conectat și configurat interfața dintre R1 și R5.
În primul rând, trebuie să reconstruim tabelul de rutare unicast pe R5 și acum se ajunge la rețeaua 192.168.1.0/24 prin interfața R5 Gi0/2. Acum R5, care primește 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. Ar trebui să se deconecteze de la RPT și să construiască un arbore mai scurt numit Arborele cel mai scurt (SPT). Pentru a face acest lucru, el trimite PIM Join la R0 prin Gi2/1 și R1 începe să trimită un multicast tot prin Gi0/2. Acum R5 trebuie să se dezaboneze de la RPT pentru a nu primi două copii. Pentru a face acest lucru, îi trimite lui Prune un mesaj indicând adresa IP sursă și inserând un bit special - RPT-bit. Asta înseamnă că nu trebuie să-mi trimiți trafic, am un copac mai bun aici. RP trimite, de asemenea, mesaje PIM Prune către R1, dar nu trimite un mesaj Register-Stop. O altă caracteristică: R5 va trimite acum continuu PIM Prune către RP, deoarece R1 continuă să trimită PIM Register către RP în fiecare minut. Până când nu vor exista oameni noi care să dorească acest trafic, RP îl va refuza. R5 notifică RP că continuă să primească multicast prin SPT.
Căutare dinamică RP.
Auto-RP.
Această tehnologie este proprietară de la Cisco și nu este deosebit de populară, dar este încă în viață. Funcționarea Auto-RP constă din două etape principale:
1) RP trimite mesaje RP-Announce la adresa rezervată - 224.0.1.39, declarându-se RP fie pentru toată lumea, fie pentru anumite grupuri. Acest mesaj este trimis în fiecare minut.
2) Este necesar un agent de mapare RP, care va trimite mesaje RP-Discovery indicând pentru ce grupuri care RP ar trebui ascultat. Din acest mesaj, routerele PIM obișnuite vor determina singuri RP. Agentul de cartografiere poate fi fie routerul RP în sine, fie un router PIM separat. RP-Discovery este trimis la adresa 224.0.1.40 cu un temporizator de un minut.
Să ne uităm la procesul mai detaliat:
Să configuram R3 ca RP:
ip pim send-rp-announce loopback 0 domeniu 10
R2 ca agent de cartografiere:
ip pim send-rp-discovery loopback 0 domeniul de aplicare 10
Și la toate celelalte ne vom aștepta la RP prin Auto-RP:
ip pim autorp ascultător
Odată ce configurăm R3, va începe să trimită RP-Announce:
Și R2, după configurarea agentului de cartografiere, va începe să aștepte mesajul RP-Announce. Numai când găsește cel puțin un RP va începe să trimită RP-Discovery:
În acest fel, de îndată ce routerele obișnuite (PIM RP Listener) primesc acest mesaj, vor ști unde să caute RP-ul.
Una dintre principalele probleme cu Auto-RP este că, pentru a primi mesaje RP-Announce și RP-Discovery, trebuie să trimiteți PIM Join la adresele 224.0.1.39-40, iar pentru a trimite, trebuie să știți unde este RP este localizat. Problemă clasică cu puiul și ouăle. Pentru a rezolva această problemă, a fost inventat PIM Sparse-Dense-Mode. Dacă routerul nu cunoaște RP, atunci funcționează în modul Dens; dacă o cunoaște, atunci în modul Sparse. Când PIM Sparse-mode și comanda ip pim autorp listener sunt configurate pe interfețele routerelor obișnuite, routerul va funcționa în modul Dense doar pentru multicasting direct din protocolul 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 cartografiere, care colectează informații de cartografiere și apoi le spune tuturor celorlalte routere. Să descriem procesul în mod similar cu Auto-RP:
1) După ce configurăm R3 ca candidat pentru a fi RP, cu comanda:
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ă un agent de cartografiere. Astfel, trecem la a doua etapă.
2) Configurați R2 ca agent de mapare:
ip pim bsr-candidate loopback 0
R2 începe să trimită mesaje PIM Bootstrap, unde se indică ca agent de mapare:
Acest mesaj este trimis la adresa 224.0.013, pe care protocolul PIM o folosește și pentru celelalte mesaje ale sale. Le trimite în toate direcțiile și, prin urmare, nu există nicio problemă cu puiul și ouă, așa cum a fost în Auto-RP.
3) De îndată ce RP primește un mesaj de la routerul BSR, va trimite imediat un mesaj unicast la adresa routerului BSR:
După care, BSR, după ce a primit informații despre RP-uri, le va trimite prin multicast la adresa 224.0.0.13, care este ascultată de toate routerele PIM. Prin urmare, un analog al comenzii ip pim autorp ascultător pentru routere obișnuite care nu sunt în BSR.
Anycast RP cu Multicast Source Discovery Protocol (MSDP).
Auto-RP și BSR ne permit să distribuim încărcătura pe RP după cum urmează: Fiecare grup multicast are un singur RP activ. Nu va fi posibilă distribuirea încărcării pentru un grup multicast peste mai multe RP-uri. MSDP face acest lucru emitând routerelor RP aceeași adresă IP cu o mască de 255.255.255.255. MSDP învață informații folosind una dintre metodele: 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 sunt utilizate pentru toate grupurile. Cu RP-Announce, ambele routere se anunță prin referire la această adresă. Agentul de cartografiere Auto-RP, după ce a primit informația, trimite RP-Discovery despre RP cu adresa 172.16.1.1/32. Le spunem routerelor despre rețeaua 172.16.1.1/32 folosind IGP și, în consecință. Astfel, routerele PIM solicită sau înregistrează fluxuri de la RP care este specificat ca următorul hop pe ruta către rețea 172.16.1.1/32. Protocolul MSDP în sine este conceput pentru ca RP-urile înșiși să facă schimb de mesaje despre informații multicast.
Luați în considerare această topologie:
Switch6 difuzează trafic la adresa 238.38.38.38 și până acum doar RP-R1 știe despre asta. Switch7 și Switch8 au solicitat acest grup. Routerele R5 și R4 vor trimite PIM Join la R1 și, respectiv, R3. De ce? Ruta către 13.13.13.13 pentru R5 se va referi la R1 folosind metrica IGP, la fel ca pentru R4.
RP-R1 știe despre flux și va începe să-l transmită către R5, dar R4 nu știe nimic despre el, deoarece R1 nu îl va trimite pur și simplu. Prin urmare, MSDP este necesar. Îl configuram 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
Ei vor ridica o sesiune între ei și atunci când primesc orice flux, îl vor raporta vecinului lor RP.
De îndată ce RP-R1 primește un flux de la Switch6, va trimite imediat un mesaj MSDP Source-Active unicast, care va conține informații precum (S, G) - informații despre sursa și destinația multicastului. Acum că RP-R3 știe că o sursă precum Switch6, atunci când primește o solicitare de la R4 pentru acest flux, va trimite PIM Join către Switch6, ghidat de tabelul de rutare. În consecință, R1 care a primit o astfel de alăturare PIM va începe să trimită trafic către RP-R3.
MSDP rulează peste TCP, RP-urile își trimit reciproc mesaje keepalive pentru a verifica gradul de viață. Cronometrul este de 60 de secunde.
Funcția de împărțire a colegilor MSDP în diferite domenii rămâne neclară, deoarece mesajele Keepalive și SA nu indică apartenența la niciun domeniu. De asemenea, în această topologie, am testat o configurație care indică diferite domenii - nu a existat nicio diferență de performanță.
Dacă cineva poate clarifica, aș fi bucuros să o citesc în comentarii.
Sursa: www.habr.com
