{"id":33142,"date":"2019-10-31T21:50:58","date_gmt":"2019-10-31T18:50:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-raboty-protokola-pim\/"},"modified":"2019-10-31T21:50:58","modified_gmt":"2019-10-31T18:50:58","slug":"printsipy-raboty-protokola-pim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Principiile de func\u021bionare ale protocolului PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Protocolul PIM este un set de protocoale pentru transmiterea multicast-ului \u00een re\u021bea \u00eentre routere. Rela\u021biile de vecin\u0103tate sunt stabilite \u00een mod similar cu cele ale protocoalelor de rutare dinamice. PIMv2 trimite mesaje Hello la fiecare 30 de secunde pe adresa multicast rezervat\u0103 224.0.0.13 (All-PIM-Routers). Mesajul con\u021bine Timerele Hold \u2014 de obicei, acestea sunt egale cu 3,5 * Hello Timer, adic\u0103 105 secunde \u00een mod implicit.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM utilizeaz\u0103 dou\u0103 moduri principale de operare \u2014 Dense \u0219i Sparse mode. S\u0103 \u00eencepem cu Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Arbori de Distribu\u021bie Bazati pe Surs\u0103.<\/b><br \/>\nModul Dense este recomandat a fi folosit \u00een cazul unui num\u0103r mare de clien\u021bi din diverse grupuri multicast. Atunci c\u00e2nd routerul prime\u0219te trafic multicast, acesta verific\u0103 mai \u00eent\u00e2i regula RPF. RPF \u2014 aceast\u0103 regul\u0103 este utilizat\u0103 pentru a verifica sursa multicast-ului cu tabela de rutare unicast. Traficul trebuie s\u0103 soseasc\u0103 pe interfa\u021ba pe care se afl\u0103 acest host conform tabelei de rutare unicast. Acest mecanism rezolv\u0103 problema apari\u021biei buclelor \u00een timpul transmiterii multicast-ului.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 din mesajul multicast afl\u0103 sursa multicast-ului (Source IP) \u0219i va verifica cele dou\u0103 fluxuri de la R1 \u0219i R2 conform tabelei sale de rutare unicast. Fluxul de pe interfa\u021ba indicat\u0103 de tabel\u0103 (R1 c\u0103tre 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.<br \/>\n\u00centrebarea este: ce se \u00eent\u00e2mpl\u0103 dac\u0103 ave\u021bi dou\u0103 rute echivalente cu aceea\u0219i metric\u0103? \u00cen acest caz, routerul va alege \u00een func\u021bie de next-hop \u00eentre aceste rute. Cel cu adresa IP mai mare va c\u00e2\u0219tiga. Dac\u0103 este necesar s\u0103 schimba\u021bi acest comportament, pute\u021bi utiliza ECMP. Mai multe detalii. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">aici<\/a><\/noindex>.<br \/>\nDup\u0103 verificarea regulii RPF, routerul trimite pachetul multicast tuturor vecinilor s\u0103i PIM, cu excep\u021bia celui de la care a fost primit acest pachet. Celelalte routere PIM repet\u0103 acest proces. Drumul parcurs de pachetul multicast de la surs\u0103 la destinatarii finali formeaz\u0103 un arbore, numit \u2014 arbore de distribu\u021bie bazat pe surs\u0103, arbore de drumuri scurte (SPT), arbore de surs\u0103. Trei denumiri diferite, alege\u021bi orice.<br \/>\nCum s\u0103 rezolv\u0103m problema c\u0103 unor routere nu le-a fost transmis un anumit flux multicast \u0219i nu au pe cine s\u0103-l trimit\u0103, dar routerul superior le trimite? Pentru aceasta a fost inventat mecanismul Prune. <br \/>\n<b>Prune Message.<\/b><br \/>\nDe exemplu, R2 va continua s\u0103 trimit\u0103 multicast c\u0103tre R3, de\u0219i R3 \u00eel elimin\u0103 conform regulii RPF. De ce s\u0103 suprasolicit\u0103m canalul? R3 trimite un mesaj PIM Prune, iar R2, la primirea acestui mesaj, va elimina interfa\u021ba S0\/1 din lista de interfe\u021be (outgoing interface list) pentru acest flux, lista interfe\u021belor de la care trebuie trimis acest trafic. <\/p>\n<blockquote><p>Urm\u0103toarea este o defini\u021bie mai formal\u0103 a unui mesaj PIM Prune:<br \/>\nMesajul PIM Prune este trimis de un router unui alt router pentru a determina al doilea router s\u0103 elimine leg\u0103tura pe care a fost primit Prune dintr-un anumit SPT (S,G).<\/p><\/blockquote>\n<p>\nLa primirea mesajului Prune, R2 seteaz\u0103 un timer Prune de 3 minute. Dup\u0103 trei minute va \u00eencepe s\u0103 trimit\u0103 din nou trafic, p\u00e2n\u0103 nu prime\u0219te un alt mesaj Prune. Aceasta este \u00een PIMv1.<br \/>\n\u00cen PIMv2 a fost ad\u0103ugat un timer State Refresh (\u00een mod implicit 60 de secunde). De \u00eendat\u0103 ce a fost trimis un mesaj Prune de la R3, acest timer se activeaz\u0103 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. <br \/>\nMotivele trimiterii unui mesaj Prune:<\/p>\n<ul>\n<li> C\u00e2nd pachetul multicast nu a trecut verificarea RPF.<\/li>\n<li> C\u00e2nd nu exist\u0103 clien\u021bi conecta\u021bi local care s\u0103 fi solicitat grupul multicast (IGMP Join) \u0219i nu sunt vecini PIM c\u0103rora s\u0103 le poat\u0103 trimite trafic multicast (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Mesaj Graft.<\/b><br \/>\nS\u0103 presupunem c\u0103 R3 nu a dorit trafic de la R2, a trimis Prune \u0219i a primit multicast de la R1. Dar dintr-o dat\u0103, canalul \u00eentre R1-R3 a c\u0103zut, iar R3 a r\u0103mas f\u0103r\u0103 multicast. Se poate a\u0219tepta 3 minute, p\u00e2n\u0103 c\u00e2nd timerul Prune de pe R2 expir\u0103. 3 minute este mult, pentru a nu a\u0219tepta, este necesar s\u0103 se trimit\u0103 un mesaj care s\u0103 scoat\u0103 instantaneu aceast\u0103 interfa\u021b\u0103 S0\/1 de pe R2 din starea pruned. Un astfel de mesaj va fi mesajul Graft. Dup\u0103 primirea mesajului Graft, R2 va trimite \u00eenapoi Graft-ACK.<br \/>\n<b>Prune Override.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zfo0Dx5.png\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nS\u0103 analiz\u0103m acest scenariu. R1 transmite multicast \u00eentr-un segment cu dou\u0103 routere. R3 prime\u0219te \u0219i transmite traficul, R2 prime\u0219te, dar nu are pe cine s\u0103 transmit\u0103. El trimite un mesaj Prune c\u0103tre R1 \u00een acest segment. R1 trebuie s\u0103 elimine Fa0\/0 din list\u0103 \u0219i s\u0103 \u00eenceteze s\u0103 transmit\u0103 \u00een acest segment, dar ce se va \u00eent\u00e2mpla cu R3? R3 se afl\u0103 \u00een acela\u0219i segment \u0219i a primit \u0219i el acest mesaj Prune, \u00een\u021beleg\u00e2nd gravitatea situa\u021biei. \u00cenainte ca R1 s\u0103 \u00eenceteze s\u0103 transmit\u0103, el seteaz\u0103 un temporizator de 3 secunde \u0219i va \u00eenceta transmisia dup\u0103 3 secunde. 3 secunde \u2014 exact at\u00e2t timp are R3 pentru a nu pierde multicast-ul s\u0103u. De aceea, R3 trimite c\u00e2t mai repede un mesaj Pim Join pentru acest grup \u0219i R1 nu mai consider\u0103 s\u0103 \u00eenceteze transmisia. Despre mesajele Join mai jos.<br \/>\n<b>Mesaj Assert.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nS\u0103 ne imagin\u0103m o situa\u021bie: \u00een aceea\u0219i re\u021bea transmit simultan dou\u0103 routere. Ele primesc acela\u0219i flux de la surs\u0103 \u0219i ambele \u00eel transmit \u00eentr-o singur\u0103 re\u021bea prin interfa\u021ba e0. Prin urmare, trebuie s\u0103Determine cine va fi singurul emitent pentru aceast\u0103 re\u021bea. Pentru aceasta se folosesc mesajele Assert. Atunci c\u00e2nd R2 \u0219i R3 detecteaz\u0103 duplicarea traficului multicast, adic\u0103 at\u00e2t pe R2 c\u00e2t \u0219i pe R3 ajunge multicast-ul pe care ele \u00eel transmit, routerele \u00een\u021beleg c\u0103 ceva nu este \u00een regul\u0103. Routerele \u00een acest caz trimit mesaje Assert, care includ Distanta Administra\u021biei \u0219i metrica rutei prin care se ajunge la sursa multicast-ului \u2014 10.1.1.10. C\u00e2\u0219tig\u0103torul se determin\u0103 astfel:<\/p>\n<ol>\n<li>Cel cu AD mai mic.<\/li>\n<li>Dac\u0103 AD-urile sunt egale, atunci cel cu metrica mai mic\u0103.<\/li>\n<li>Dac\u0103 \u0219i aici exist\u0103 egalitate, atunci cel cu IP-ul mai mare \u00een re\u021beaua \u00een care transmit acest multicast.<\/li>\n<\/ol>\n<p>\nC\u00e2\u0219tig\u0103torul acestei vot\u0103ri devine Routerul Designat. Pentru a alege DR se folosesc de asemenea Pim Hello. La \u00eenceputul articolului a fost prezentat mesajul PIM Hello, unde se poate observa c\u00e2mpul DR. C\u00e2\u0219tig\u0103 cel cu adresa IP mai mare pe acest link.<br \/>\nO tabel\u0103 util\u0103:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>Tabel MROUTE.<\/b><br \/>\nDup\u0103 analiza ini\u021bial\u0103 a func\u021bion\u0103rii protocolului PIM, trebuie s\u0103 \u00een\u021belegem cum s\u0103 lucr\u0103m cu tabela de rutare multicast. \u00cen tabela mroute se stocheaz\u0103 informa\u021bii despre ce fluxuri au fost solicitate de clien\u021bi \u0219i ce fluxuri sunt transmise de serverele multicast. <br \/>\nDe exemplu, la primirea unui IGMP Membership Report sau PIM Join pe o interfa\u021b\u0103, se adaug\u0103 o \u00eenregistrare de tip (*, G) \u00een tabela de rutare:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nAceast\u0103 \u00eenregistrare semnific\u0103 faptul c\u0103 a fost primit o cerere de trafic de la adresa 238.38.38.38. Flacul DC indic\u0103 faptul c\u0103 multicast-ul va func\u021biona \u00een modul Dense mode, iar C \u00eenseamn\u0103 c\u0103 destinatarul este direct conectat la router, adic\u0103 routerul a primit IGMP Membership Report \u0219i PIM Join.<br \/>\nDac\u0103 exist\u0103 o \u00eenregistrare de tip (S,G), aceasta \u00eenseamn\u0103 c\u0103 avem un flux multicast:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n\u00cen c\u00e2mpul S \u2014 192.168.1.11, avem adresa IP a sursei multicast; aceasta va fi verificat\u0103 de regula RPF. \u00cen caz de probleme, primul lucru de verificat este tabela unicast pentru ruta c\u0103tre surs\u0103. \u00cen c\u00e2mpul Incoming Interface se specific\u0103 interfa\u021ba pe care ajunge multicast-ul. \u00cen tabela de rutare unicast, ruta c\u0103tre surs\u0103 trebuie s\u0103 fac\u0103 referire la interfa\u021ba specificat\u0103 aici. \u00cen Outgoing Interface se specific\u0103 unde va fi redirec\u021bionat multicast-ul. Dac\u0103 este gol, \u00eenseamn\u0103 c\u0103 c\u0103tre router nu au fost trimise cereri pentru acest trafic. Informa\u021bii mai detaliate despre toate flagurile pot fi g\u0103site <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">aici<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nStrategia Sparse-mode este opus\u0103 Dense-mode. C\u00e2nd Sparse-mode prime\u0219te trafic multicast, va trimite traficul doar prin acele interfe\u021be unde au fost cereri pentru acest flux, de exemplu mesaje Pim Join sau IGMP Report cu cererea pentru acest trafic.<br \/>\nElementele similare \u00eentre SM \u0219i DM:<\/p>\n<ul>\n<li> Rela\u021biile de vecin\u0103tate sunt stabilite la fel ca \u00een PIM DM.<\/li>\n<li> Regula RPF func\u021bioneaz\u0103.<\/li>\n<li> Alegerea DR este similar\u0103.<\/li>\n<li> Mecanismul Prune Overrides \u0219i mesajele Assert sunt similare.<\/li>\n<\/ul>\n<p>\nPentru a controla cine, unde \u0219i ce trafic multicast este necesar \u00een re\u021bea, este nevoie de un centru informa\u021bional comun. Acest centru va fi Rendezvous Point (RP). To\u021bi cei care doresc trafic multicast sau cei care au \u00eenceput s\u0103 primeasc\u0103 trafic multicast de la surs\u0103, trimite cererea la RP.<br \/>\nC\u00e2nd RP prime\u0219te trafic multicast, va trimite c\u0103tre acei routeri care au solicitat anterior acest trafic. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nS\u0103 ne imagin\u0103m o topologie \u00een care RP este R3. De \u00eendat\u0103 ce R1 prime\u0219te trafic de la S1, acesta va \u00eencapsula pachetul multicast \u00een mesajul unicast PIM Register \u0219i \u00eel va trimite la RP. De unde \u0219tie cine este RP? \u00cen acest caz, este configurat static, iar despre configurarea dinamic\u0103 a RP vom discuta mai t\u00e2rziu. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP se va uita - a existat informa\u021bia de la cineva care ar dori s\u0103 primeasc\u0103 acest trafic? Presupunem c\u0103 nu a fost. Atunci, RP va trimite un mesaj R1 PIM Register-Stop, ceea ce \u00eenseamn\u0103 - nim\u0103nui nu-i trebuie acest multicast, \u00eenregistrarea este refuzat\u0103. R1 nu va trimite multicast. Dar sursa host-ului multicast va continua s\u0103-l trimit\u0103, a\u0219a c\u0103 R1, dup\u0103 ce prime\u0219te Register-Stop, va porni un temporizator Register-Suppression, setat pe 60 de secunde. Cu 5 secunde \u00eenainte de expirarea acestui temporizator, R1 va trimite un mesaj Register gol cu bitul Null-Register (adic\u0103 f\u0103r\u0103 pachetul multicast \u00eencapsulat) c\u0103tre RP. RP, la r\u00e2ndul s\u0103u, va ac\u021biona astfel:<\/p>\n<ul>\n<li> Dac\u0103 nu au existat destinatari, el va r\u0103spunde cu un mesaj Register-Stop.<\/li>\n<li> Dac\u0103 au ap\u0103rut destinatari, el nu va r\u0103spunde deloc. R1, nesemnalandu-se refuzul pe \u00eenregistrare \u00een termen de 5 secunde, se va bucura \u0219i va trimite un mesaj Register cu multicast \u00eencapsulat c\u0103tre RP.<\/li>\n<\/ul>\n<p>\nCum ajunge multicastul la RP pare c\u0103 s-a l\u0103murit, acum s\u0103 \u00eencerc\u0103m s\u0103 r\u0103spundem la \u00eentrebarea cum RP aduce traficul la destinatari. Aici trebuie introdus un nou concept - arborele root-path (RPT). RPT - este un arbore cu r\u0103d\u0103cina \u00een RP, cresc\u00e2nd spre destinatari, ramific\u00e2ndu-se la fiecare router PIM-SM. RP \u00eel creeaz\u0103, primind mesaje PIM Join \u0219i adaug\u0103 o nou\u0103 ramur\u0103 \u00een arbore. Astfel, fiecare router inferior face la fel. Regula general\u0103 este urm\u0103toarea:<\/p>\n<ul>\n<li> C\u00e2nd un router PIM-SM prime\u0219te un mesaj PIM Join pe orice interfa\u021b\u0103, cu excep\u021bia interfe\u021bei care ascunde RP, el adaug\u0103 o nou\u0103 ramur\u0103 \u00een arbore.<\/li>\n<li> De asemenea, o ramur\u0103 se adaug\u0103 atunci c\u00e2nd un router PIM-SM prime\u0219te un raport de apartenen\u021b\u0103 IGMP de la un host conectat direct. <\/li>\n<\/ul>\n<p>\nS\u0103 ne imagin\u0103m c\u0103 avem un client multicast pe routerul R5 pe grupul 228.8.8.8. De \u00eendat\u0103 ce R5 prime\u0219te un raport de apartenen\u021b\u0103 IGMP de la host, R5 trimite PIM Join c\u0103tre RP \u0219i adaug\u0103 interfa\u021ba care vede c\u0103tre host \u00een arbore. Apoi, R4 prime\u0219te PIM Join de la R5, adaug\u0103 interfa\u021ba Gi0\/1 \u00een arbore \u0219i trimite PIM Join c\u0103tre RP. \u00cen final, RP (R3) prime\u0219te PIM Join \u0219i adaug\u0103 Gi0\/0 \u00een arbore. Astfel, se ob\u021bine \u00eenregistrarea destinatarului multicast. Se construie\u0219te un arbore cu r\u0103d\u0103cina R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nDup\u0103 aceasta, PIM Join va fi trimis c\u0103tre R1 \u0219i R1 va \u00eencepe s\u0103 trimit\u0103 trafic multicast. Este important de men\u021bionat c\u0103, dac\u0103 hostul a solicitat trafic \u00eenainte de a \u00eencepe difuzarea multicast-ului, RP nu va trimite PIM Join \u0219i, \u00een general, nu va trimite nimic c\u0103tre R1.<br \/>\nDac\u0103, \u00een timp ce se trimite multicast, hostul nu mai dore\u0219te s\u0103-l primeasc\u0103, de \u00eendat\u0103 ce RP prime\u0219te PIM Prune pe interfa\u021ba Gi0\/0, va trimite imediat PIM Register-Stop direct c\u0103tre R1, iar apoi un mesaj PIM Prune prin interfa\u021ba Gi0\/1. PIM Register-stop este trimis unicast c\u0103tre adresa de pe care a venit PIM Register.<br \/>\nA\u0219a cum am men\u021bionat anterior, de \u00eendat\u0103 ce routerul trimite PIM Join altuia, de exemplu R5 c\u0103tre R4, o \u00eenregistrare este ad\u0103ugat\u0103 pe R4:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n\u0218i se activeaz\u0103 un temporizator, ceea ce \u00eenseamn\u0103 c\u0103 R5 trebuie s\u0103 trimit\u0103 constant mesaje PIM Join, altfel R4 va exclude lista de ie\u0219ire. R5 va trimite mesaje PIM Join la fiecare 60 de secunde.<br \/>\n<b>Schimbarea arborelui de cea mai scurt\u0103 cale.<\/b><br \/>\nVom ad\u0103uga o interfa\u021b\u0103 \u00eentre R1 \u0219i R5, s\u0103 vedem cum va curge traficul cu aceast\u0103 topologie. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nS\u0103 presupunem c\u0103 traficul a fost trimis \u0219i primit conform vechii scheme R1-R2-R3-R4-R5 \u0219i acum am conectat \u0219i configurat interfa\u021ba \u00eentre R1 \u0219i R5.<br \/>\n\u00cen primul r\u00e2nd, tabela de rutare unicast de pe R5 se va reconstrui \u0219i acum re\u021beaua 192.168.1.0\/24 este accesibil\u0103 prin interfa\u021ba R5 Gi0\/2. Acum, R5 primind multicast pe interfa\u021ba Gi0\/1, \u00een\u021belege c\u0103 regula RPF nu este satisf\u0103cut\u0103 \u0219i ar fi mai logic s\u0103 primeasc\u0103 multicast pe Gi0\/2. El trebuie s\u0103 se deconecteze de la RPT \u0219i s\u0103 construiasc\u0103 un arbore mai scurt, numit Shortest-Path Tree (SPT). Pentru aceasta trimite PIM Join pe R1 prin Gi0\/2, iar R1 \u00eencepe s\u0103 trimit\u0103 multicast \u0219i prin Gi0\/2. Acum, R5 trebuie s\u0103 se dezaboneze de la RPT pentru a nu primi dou\u0103 copii. Pentru aceasta, trimite un mesaj Prune specific\u00e2nd adresa IP a sursei \u0219i ad\u0103ug\u00e2nd un bit special \u2014 RPT-bit. Acest lucru \u00eenseamn\u0103 c\u0103 nu trebuie s\u0103-mi trimi\u021bi trafic, am aici un arbore mai bun. RP trimite de asemenea mesaje PIM Prune c\u0103tre R1, dar nu trimite mesajul Register-Stop. O alt\u0103 caracteristic\u0103: R5 va trimite constant PIM Prune c\u0103tre RP, deoarece R1 continu\u0103 s\u0103 trimit\u0103 PIM Register c\u0103tre RP \u00een fiecare minut. RP, p\u00e2n\u0103 nu vor exista noi doritori pentru acest trafic, \u00eei va r\u0103spunde cu un refuz. R5 notific\u0103 RP c\u0103 continu\u0103 s\u0103 primeasc\u0103 multicast prin SPT.<br \/>\n<b>C\u0103utarea dinamic\u0103 RP. <br \/>\nAuto-RP.<\/b><br \/>\nAceast\u0103 tehnologie este proprietar\u0103 Cisco \u0219i nu este foarte popular\u0103, dar \u00eenc\u0103 exist\u0103. Func\u021bionarea Auto-RP const\u0103 \u00een dou\u0103 etape principale:<br \/>\n1) RP trimite mesaje RP-Announce la adresa rezervat\u0103 \u2014 224.0.1.39, anun\u021b\u00e2ndu-se ca RP fie pentru toate grupurile, fie pentru anumite grupuri. Acest mesaj este trimis la fiecare minut.<br \/>\n2) Este necesar un agent de mapare RP, care va trimite mesaje RP-Discovery indic\u00e2nd pentru ce grupuri trebuie s\u0103 asculte fiecare RP. Din acest mesaj, routerele PIM obi\u0219nuite \u00ee\u0219i vor determina RP-ul. Agentul de mapare poate fi fie routerul RP \u00eensu\u0219i, fie un alt router PIM separat. RP-Discovery este trimis la adresa 224.0.1.40 cu un timer de un minut.<br \/>\nS\u0103 discut\u0103m procesul \u00een detaliu:<br \/>\nConfigura\u021bi R3 ca RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 ca agent de mapare:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nIar pe toate celelalte vom a\u0219tepta RP prin Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nOdat\u0103 ce configur\u0103m R3, acesta va \u00eencepe s\u0103 trimit\u0103 RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDup\u0103 ce R2 este configurat ca agent de mapare, acesta va \u00eencepe s\u0103 a\u0219tepte mesajele RP-Announce. Numai c\u00e2nd g\u0103se\u0219te cel pu\u021bin un RP, va \u00eencepe s\u0103 trimit\u0103 RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nAstfel, de \u00eendat\u0103 ce routerele obi\u0219nuite ( PIM RP Listener ) primesc acest mesaj, ele vor \u0219ti unde s\u0103 caute RP.<br \/>\nUna dintre principalele probleme ale Auto-RP este c\u0103 pentru a primi mesajele RP-Announce \u0219i RP-Discovery este necesar s\u0103 se trimit\u0103 PIM Join la adresele 224.0.1.39-40, iar pentru a trimite, trebuie s\u0103 \u0219tim unde se afl\u0103 RP. Este o problem\u0103 clasic\u0103 de tipul g\u0103inii \u0219i oului. Pentru a rezolva aceast\u0103 problem\u0103, a fost inventat modul PIM Sparse-Dense-Mode. Dac\u0103 routerul nu \u0219tie de RP, atunci func\u021bioneaz\u0103 \u00een modul Dense-mode, iar dac\u0103 \u0219tie, atunci \u00een modul Sparse-mode. C\u00e2nd pe interfe\u021bele routerelor obi\u0219nuite este configurat PIM Sparse-mode \u0219i comanda ip pim autorp listener, routerul va func\u021biona \u00een modul Dense-mode doar pentru multicastul protocolului Auto-RP ( 224.0.1.39-40 ).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nAceast\u0103 func\u021bie func\u021bioneaz\u0103 similar cu Auto-RP. Fiecare RP trimite un mesaj agentului de mapare, care adun\u0103 informa\u021biile de mapare \u0219i apoi le comunic\u0103 tuturor celorlalte routere. S\u0103 descriem procesul similar cu Auto-RP:<br \/>\n1) De \u00eendat\u0103 ce configur\u0103m R3 ca fiind candidatul pentru a fi RP, prin comand\u0103:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nAtunci R3 nu va face nimic, pentru a \u00eencepe s\u0103 trimit\u0103 mesaje speciale, trebuie mai \u00eent\u00e2i s\u0103 g\u0103seasc\u0103 agentul de mapare. Astfel, trecem la pasul doi.<br \/>\n2) Configur\u0103m R2 ca agent de mapare:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 \u00eencepe s\u0103 trimit\u0103 mesaje PIM Bootstrap, \u00een care se indic\u0103 pe sine ca agent de mapping:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nAcest mesaj este trimis la adresa 224.0.0.13, pe care protocolul PIM o folose\u0219te \u0219i pentru alte mesaje. Acesta le trimite \u00een toate direc\u021biile, astfel c\u0103 nu exist\u0103 problema oului \u0219i a puiului, a\u0219a cum era la Auto-RP.<br \/>\n3) De \u00eendat\u0103 ce RP prime\u0219te un mesaj de la routerul BSR, acesta va trimite imediat un mesaj unicast la adresa routerului BSR:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDup\u0103 aceea, BSR, primind informa\u021biile despre RP, le va trimite prin multicast la adresa 224.0.0.13, pe care o ascult\u0103 toate routerele PIM. Prin urmare, nu exist\u0103 un echivalent pentru comanda <i>ip pim autorp listener<\/i> pentru routerele obi\u0219nuite \u00een BSR.<br \/>\n<b>Anycast RP cu Protocolul de Descoperire a Sursei Multicast (MSDP).<\/b><br \/>\nAuto-RP \u0219i BSR ne permit s\u0103 distribuit\u0103 sarcina pe RP \u00een urm\u0103torul mod: Fiecare grup multicast are un singur RP activ. Nu se poate realiza o distribu\u021bie a sarcinii pentru un grup multicast cu mai multe RP-uri. MSDP face acest lucru prin atribuirea routerelor RP a acelea\u0219i adrese IP cu masca 255.255.255.255. MSDP afl\u0103 informa\u021bii prin una dintre metode: static\u0103, Auto-RP sau BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n\u00cen imagine avem o configura\u021bie Auto-RP cu MSDP. Ambele RP-uri sunt configurate cu adresa IP 172.16.1.1\/32 pe interfa\u021ba Loopback 1 \u0219i este folosit\u0103 pentru toate grupurile. La RP-Announce, ambele routere se anun\u021b\u0103 reciproc, referindu-se la aceast\u0103 adres\u0103. Agentul de mapping Auto-RP, primind informa\u021biile, trimite RP-Discovery despre RP cu adresa 172.16.1.1\/32. Despre re\u021beaua 172.16.1.1\/32, inform\u0103m routerele prin IGP \u0219i, \u00een consecin\u021b\u0103. Astfel, routerele PIM solicit\u0103 sau se \u00eenregistreaz\u0103 pentru fluxuri de la RP-ul care este indicat ca next-hop \u00een ruta c\u0103tre re\u021beaua 172.16.1.1\/32. Protocolul MSDP este destinat RP-urilor pentru a schimba mesaje despre informa\u021biile multicast.<br \/>\nS\u0103 analiz\u0103m o astfel de topologie:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Principiile de func\u021bionare ale protocolului PIM\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 transmite trafic la adresa 238.38.38.38 \u0219i deocamdat\u0103 doar RP-R1 \u0219tie acest lucru. Switch7 \u0219i Switch8 au solicitat acest grup. Routerele R5 \u0219i R4 vor trimite PIM Join la R1 \u0219i R3, respectiv. De ce? Ruta c\u0103tre 13.13.13.13 la R5 va face referire la R1 prin metrica IGP, la fel ca \u0219i la R4.<br \/>\nRP-R1 \u0219tie despre flux \u0219i va \u00eencepe s\u0103-l transmit\u0103 c\u0103tre R5, \u00eens\u0103 R4 nu \u0219tie nimic despre el, deoarece R1 nu \u00eel va trimite pur \u0219i simplu. De aceea, MSDP este necesar. \u00cel configur\u0103m pe R1 \u0219i R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 pe R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 pe R3<\/p><\/blockquote>\n<p>\nAcestea vor stabili o sesiune \u00eentre ele \u0219i, atunci c\u00e2nd primesc un flux, vor anun\u021ba RP-ul vecin despre acesta.<br \/>\nRP-R1 va trimite imediat un mesaj MSDP Source-Active prin unicast atunci c\u00e2nd va primi fluxul de la Switch6, care va con\u021bine informa\u021bii de tip (S, G) \u2013 informa\u021bii despre surs\u0103 \u0219i destina\u021bia multicast. Acum, c\u00e2nd RP-R3 va \u0219ti c\u0103 exist\u0103 o surs\u0103 precum Switch6, la primirea unei cereri de la R4 pentru acest flux, va trimite PIM Join c\u0103tre Switch6, conform tabelului de rutare. Prin urmare, R1, primind acest PIM Join, va \u00eencepe s\u0103 trimit\u0103 traficul c\u0103tre RP-R3.<br \/>\nMSDP func\u021bioneaz\u0103 pe TCP, RP-uri \u00ee\u0219i trimit unul altuia mesaje keepalive pentru a verifica viabilitatea. Timerul este de 60 de secunde.<br \/>\nFunc\u021bia de separare a piroanelor MSDP \u00een domenii diferite r\u0103m\u00e2ne neclar\u0103, deoarece \u00een mesajele Keepalive \u0219i SA nu se specific\u0103 apartenen\u021ba la vreun domeniu. De asemenea, \u00een aceast\u0103 topologie s-a testat o configura\u021bie cu specificarea diferitelor domenii \u2013 nu au fost observate diferen\u021be \u00een func\u021bionare. <br \/>\nDac\u0103 cineva poate aduce l\u0103muriri, a\u0219 fi bucuros s\u0103 citesc \u00een comentarii.<br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450582\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33142","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Principiile de func\u021bionare ale protocolului PIM | ProHoster","description":"Protocolul PIM este un set de protocoale pentru transmiterea multicast-ului \u00een re\u021bea \u00eentre routere. Rela\u021biile de vecin\u0103tate sunt stabilite similar cu cele din cazul protocoalelor de rutare dinamice.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster","og:description":"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:50:58+00:00","article:modified_time":"2019-10-31T18:50:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33142","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 14:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:46:23","updated":"2026-01-21 14:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}