{"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\/sk\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Princ\u00edpy fungovania protokolu PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Protokol PIM je s\u00fabor protokolov na prenos multicastu v sieti medzi smerova\u010dmi. Vz\u0165ahy susedstva sa buduj\u00fa podobne ako v pr\u00edpade dynamick\u00fdch smerovac\u00edch protokolov. PIMv2 posiela ka\u017ed\u00fdch 30 sek\u00fand spr\u00e1vy Hello na vyhraden\u00fa multicastov\u00fa adresu 224.0.0.13 (All-PIM-Routers). Spr\u00e1va obsahuje Hold Timers \u2013 zvy\u010dajne je nastaven\u00fd na 3,5-n\u00e1sobok Hello Timera, teda 105 sek\u00fand ako predvolen\u00e9.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM pou\u017e\u00edva dva hlavn\u00e9 re\u017eimy prev\u00e1dzky \u2013 Dense a Sparse mode. Za\u010dneme s Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Distribu\u010dn\u00e9 stromy zalo\u017een\u00e9 na zdroji.<\/b><br \/>\nRe\u017eim Dense-mode je rozumn\u00e9 pou\u017ei\u0165 v pr\u00edpade ve\u013ek\u00e9ho po\u010dtu klientov v r\u00f4znych multicastov\u00fdch skupin\u00e1ch. Ke\u010f smerova\u010d dostane multicastov\u00fd prenos, najprv skontroluje pravidlo RPF. RPF \u2013 toto pravidlo sa pou\u017e\u00edva na kontrolu zdroja multicastu s jednosmernou smerovacou tabu\u013ekou. Trafik mus\u00ed prich\u00e1dza\u0165 na ten rozhranie, za ktor\u00fdm sa nach\u00e1dza dan\u00fd host pod\u013ea jednosmernej smerovacej tabu\u013eky. Tento mechanizmus rie\u0161i probl\u00e9m vzniku slu\u010diek pri prenose multicastu.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 z multicastov\u00fdch spr\u00e1v zist\u00ed zdroj multicastu (Source IP) a skontroluje dva toky od R1 a R2 pod\u013ea svojej jednosmernej tabu\u013eky. Tok z toho rozhrania, na ktor\u00e9 odkazuje tabu\u013eka (R1 k R3), bude pren\u00e1\u0161an\u00fd \u010falej, zatia\u013e \u010do tok od R2 bude zru\u0161en\u00fd, preto\u017ee na to, aby sa dostalo k zdroju multicastu, je potrebn\u00e9 posiela\u0165 pakety cez S0\/1.<br \/>\n\u010co sa stane, ak m\u00e1te dve ekvivalentn\u00e9 trasy s rovnakou metrikou? V tomto pr\u00edpade smerova\u010d vyber\u00e1 pod\u013ea next-hop t\u00fdchto tr\u00e1s. Kto m\u00e1 vy\u0161\u0161iu IP adresu, ten vyhr\u00e1va. Ak je potrebn\u00e9 zmeni\u0165 toto spr\u00e1vanie, je mo\u017en\u00e9 pou\u017ei\u0165 ECMP. Viac inform\u00e1ci\u00ed. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">tu<\/a><\/noindex>.<br \/>\nPo overen\u00ed pravidla RPF smerova\u010d odosiela multicastov\u00fd paket v\u0161etk\u00fdm svojim PIM susedom, okrem toho, od koho bol tento paket prijat\u00fd. Ostatn\u00e9 PIM smerova\u010de opakuj\u00fa tento proces. Cesta, ktorou pre\u0161iel multicastov\u00fd paket od zdroja k kone\u010dn\u00fdm prij\u00edmate\u013eom, vytv\u00e1ra strom, ktor\u00fd sa naz\u00fdva \u2013 strom zalo\u017een\u00fd na zdroji, strom najkrat\u0161ej cesty (SPT), zdrojov\u00fd strom. Tri r\u00f4zne n\u00e1zvy, vyberte si ak\u00fdko\u013evek.<br \/>\nAko vyrie\u0161i\u0165 probl\u00e9m s t\u00fdm, \u017ee niektor\u00e9 smerova\u010de nez\u00edskali nejak\u00fd multicastov\u00fd prenos a nem\u00e1 ho komu odosla\u0165, zatia\u013e \u010do im vy\u0161\u0161\u00ed smerova\u010d posiela. Na tento \u00fa\u010del bol vymyslen\u00fd mechanizmus Prune. <br \/>\n<b>Prune Message.<\/b><br \/>\nNapr\u00edklad, R2 bude na\u010falej posiela\u0165 R3 multicast, aj ke\u010f R3 pod\u013ea pravidla RPF ho odmieta. Pre\u010do za\u0165a\u017eova\u0165 prenosov\u00fa linku? R3 posiela PIM Prune Message a R2, pri prijat\u00ed tejto spr\u00e1vy, odstr\u00e1ni rozhranie S0\/1 zo zoznamu (outgoing interface list) pre tento tok, zoznam rozhran\u00ed, z ktor\u00fdch sa m\u00e1 posiela\u0165 tento prenos. <\/p>\n<blockquote><p>Nasleduje form\u00e1lnej\u0161ia defin\u00edcia PIM Prune spr\u00e1vy:<br \/>\nPIM Prune spr\u00e1va je odoslan\u00e1 jedn\u00fdm smerova\u010dom druh\u00e9mu smerova\u010du, aby sp\u00f4sobil, \u017ee druh\u00fd smerova\u010d odstr\u00e1ni odkaz, na ktorom bola prijat\u00e1 Prune spr\u00e1va, z konkr\u00e9tneho (S,G) SPT.<\/p><\/blockquote>\n<p>\nPo prijat\u00ed Prune spr\u00e1vy, R2 nastav\u00ed Prune \u010dasova\u010d na 3 min\u00faty. Po uplynut\u00ed troch min\u00fat za\u010dne op\u00e4\u0165 posiela\u0165 prenos, pokia\u013e neobdr\u017e\u00ed \u010fal\u0161iu Prune spr\u00e1vu. To plat\u00ed pre PIMv1.<br \/>\nA v PIMv2 bol pridan\u00fd State Refresh \u010dasova\u010d (predvolene 60 sek\u00fand). Ke\u010f bola odoslan\u00e1 Prune spr\u00e1va z R3, tento \u010dasova\u010d sa spust\u00ed na R3. Po uplynut\u00ed tohto \u010dasova\u010da, R3 odo\u0161le State Refresh spr\u00e1vu, ktor\u00e1 resetuje 3-min\u00fatov\u00fd Prune \u010dasova\u010d na R2 pre t\u00fato skupinu. <br \/>\nD\u00f4vody na odoslanie Prune spr\u00e1vy:<\/p>\n<ul>\n<li> Ke\u010f multicastov\u00fd paket neprejde RPF kontrolou.<\/li>\n<li> Ke\u010f neexistuj\u00fa lok\u00e1lne pripojen\u00ed klienti, ktor\u00ed po\u017eiadali o multicastov\u00fa skupinu (IGMP Join) a niet PIM susedov, ktor\u00fdm by bolo mo\u017en\u00e9 odosiela\u0165 multicastov\u00fd prenos (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Graft Spr\u00e1va.<\/b><br \/>\nPredstavme si, \u017ee R3 nechcel prenos od R2, poslal Prune a dost\u00e1val multicast od R1. Ale zrazu, do\u0161lo k v\u00fdpadku linky medzi R1-R3 a R3 ostal bez multicastu. \u010cak\u00e1 sa 3 min\u00faty, k\u00fdm na R2 nevypr\u0161\u00ed Prune \u010dasova\u010d. \u010cakanie 3 min\u00faty je dlh\u00e9, aby sme nemuseli \u010daka\u0165, je potrebn\u00e9 posla\u0165 spr\u00e1vu, ktor\u00e1 okam\u017eite vyvedie toto rozhranie S0\/1 na R2 z pruned stavu. Takou spr\u00e1vou bude Graft spr\u00e1va. Po prijat\u00ed Graft spr\u00e1vy, R2 odo\u0161le sp\u00e4\u0165 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=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPozrime sa na t\u00fato sch\u00e9mu. R1 vysiela multicast do segmentu s dvoma smerova\u010dmi. R3 prij\u00edma a vysiela prev\u00e1dzku, R2 prij\u00edma, ale nem\u00e1 komu vysiela\u0165. Posiela Prune spr\u00e1vu k R1 do tohto segmentu. R1 by mal odstr\u00e1ni\u0165 Fa0\/0 zo zoznamu a presta\u0165 vysiela\u0165 do tohto segmentu, ale \u010do sa stane s R3? R3 je v tom istom segmente, tie\u017e prijal t\u00fato Prune spr\u00e1vu a pochopil cel\u00fa trag\u00e9diu situ\u00e1cie. Pred t\u00fdm, ako R1 prestane vysiela\u0165, nastav\u00ed \u010dasova\u010d na 3 sekundy a prestane vysiela\u0165 o 3 sekundy. 3 sekundy \u2014 presne to\u013eko \u010dasu m\u00e1 R3 na to, aby nestratil svoj multicast. Preto R3 \u010do najsk\u00f4r posiela Pim Join spr\u00e1vu pre t\u00fato skupinu a R1 u\u017e neuva\u017euje o tom, \u017ee prestane vysiela\u0165. O Join spr\u00e1vach ni\u017e\u0161ie.<br \/>\n<b>Assert Message.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPredstavme si tak\u00fa situ\u00e1ciu: do jednej siete vysielaj\u00fa naraz dva smerova\u010de. Prij\u00edmaj\u00fa ten ist\u00fd pr\u00fad zo zdroja, a obaja ho vysielaj\u00fa do jednej siete za rozhran\u00edm e0. Preto musia ur\u010di\u0165, kto bude jedin\u00fdm vysielate\u013eom pre t\u00fato sie\u0165. Na tento \u00fa\u010del sa pou\u017e\u00edvaj\u00fa Assert spr\u00e1vy. Ke\u010f R2 a R3 zistia duplicitu multicastovej prev\u00e1dzky, t.j. na R2 a R3 prich\u00e1dza multicast, ktor\u00fd sami vysielaj\u00fa, smerova\u010de ch\u00e1pu, \u017ee tu je nie\u010do v neporiadku. Smerova\u010de v tomto pr\u00edpade posielaj\u00fa Assert spr\u00e1vy, do ktor\u00fdch zahrnuj\u00fa Administrat\u00edvnu vzdialenos\u0165 a metriku trasy, pomocou ktorej sa dosahuje zdroj multicastu \u2014 10.1.1.10. V\u00ed\u0165az sa ur\u010duje takto:<\/p>\n<ol>\n<li>Ten, kto m\u00e1 ni\u017e\u0161iu AD.<\/li>\n<li>Ak s\u00fa AD rovnak\u00e9, tak ten, kto m\u00e1 ni\u017e\u0161iu metriku.<\/li>\n<li>Ak je aj tu rovnos\u0165, tak ten, kto m\u00e1 vy\u0161\u0161iu IP v sieti, do ktorej vysielaj\u00fa tento multicast.<\/li>\n<\/ol>\n<p>\nV\u00ed\u0165az v tomto hlasovan\u00ed sa st\u00e1va Designated Router-om. Na v\u00fdber DR sa taktie\u017e pou\u017e\u00edvaj\u00fa Pim Hello. Na za\u010diatku \u010dl\u00e1nku bolo zobrazen\u00e9 PIM Hello spr\u00e1va, tam m\u00f4\u017eete spozorova\u0165 pole DR. V\u00ed\u0165az\u00ed ten, kto m\u00e1 vy\u0161\u0161ie IP adresy na tomto linku.<br \/>\nU\u017eito\u010dn\u00e1 tabu\u013eka:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE Table.<\/b><br \/>\nPo prvotnom presk\u00faman\u00ed fungovania PIM protokolu mus\u00edme pochopi\u0165, ako pracova\u0165 s multicastovou routovacou tabu\u013ekou. V tabu\u013eke mroute sa uchov\u00e1va inform\u00e1cia o tom, ak\u00e9 pr\u00fady boli po\u017eadovan\u00e9 zo strany klientov a ak\u00e9 pr\u00fady prich\u00e1dzaj\u00fa z multicastov\u00fdch serverov. <br \/>\nNapr\u00edklad, pri prijat\u00ed IGMP Membership Report alebo PIM Join na nejakom rozhran\u00ed sa do routovacej tabu\u013eky prid\u00e1va z\u00e1znam typu ( *, G ):<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nT\u00e1to z\u00e1znam znamen\u00e1, \u017ee bola prijat\u00e1 \u017eiados\u0165 o prenos z adresy 238.38.38.38. Pr\u00edznak DC znamen\u00e1, \u017ee multicast bude fungova\u0165 v re\u017eime Dense mode a C znamen\u00e1, \u017ee prij\u00edma\u010d je priamo pripojen\u00fd k smerova\u010du, t.j. smerova\u010d prijal IGMP Membership Report, a PIM Join.<br \/>\nAk je z\u00e1znam typu (S,G), znamen\u00e1 to, \u017ee m\u00e1me multicastov\u00fd prenos:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nV poli S \u2014 192.168.1.11, m\u00e1me uveden\u00fa IP adresu zdroja multicastu, ktor\u00e1 bude overovan\u00e1 pravidlom RPF. V pr\u00edpade probl\u00e9mov je prv\u00e9, \u010do treba skontrolova\u0165, smerovaciu tabu\u013eku unicastu na trasu k zdroju. V poli Incoming Interface sa uv\u00e1dza interface, na ktor\u00fd prich\u00e1dza multicast. V smerovacej tabu\u013eke unicastu by mala trasa k zdroju odkazova\u0165 na interface, ktor\u00fd je tu uveden\u00fd. V Outgoing Interface sa uv\u00e1dza, kam bude multicast presmerovan\u00fd. Ak je pr\u00e1zdne, znamen\u00e1 to, \u017ee k smerova\u010du nepri\u0161li \u017eiadosti o tento prenos. Podrobnej\u0161ie inform\u00e1cie o v\u0161etk\u00fdch pr\u00edznakoch n\u00e1jdete <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">tu<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nStrat\u00e9gia Sparse-mode je opa\u010dn\u00e1 k Dense-mode. Ke\u010f Sparse-mode dostane multicastov\u00fd prenos, po\u0161le prenos iba cez tie interface, kde boli \u017eiadosti o dan\u00fd prenos, napr\u00edklad Pim Join alebo IGMP Report spr\u00e1vy s \u017eiados\u0165ou o tento prenos.<br \/>\nPodobn\u00e9 prvky u SM a DM:<\/p>\n<ul>\n<li> Vztahy susedstva sa buduj\u00fa rovnako ako v PIM DM.<\/li>\n<li> Pravidlo RPF funguje.<\/li>\n<li> V\u00fdber DR je podobn\u00fd.<\/li>\n<li> Mechanizmus Prune Overrides a spr\u00e1vy Assert s\u00fa analogick\u00e9.<\/li>\n<\/ul>\n<p>\nNa kontrolu toho, kto, kde a ak\u00fd multicastov\u00fd prenos potrebuje v sieti, potrebujeme spolo\u010dn\u00e9 informa\u010dn\u00e9 centrum. T\u00fdmto centrom bude Rendezvous Point (RP). V\u0161etci, ktor\u00ed chc\u00fa nejak\u00fd multicastov\u00fd prenos alebo niekto za\u010dal prij\u00edma\u0165 multicastov\u00fd prenos od zdroja, ho po\u0161l\u00fa na RP.<br \/>\nKe\u010f RP obdr\u017e\u00ed multicastov\u00fd prenos, po\u0161le ho t\u00fdm smerova\u010dom, ktor\u00e9 predt\u00fdm po\u017eiadali o tento prenos. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPredstavme si tak\u00fa topol\u00f3giu, kde RP je R3. Hne\u010f ako R1 z\u00edska prenos od S1, zabal\u00ed tento multicastov\u00fd paket do unicastov\u00e9ho PIM Register spr\u00e1vy a po\u0161le ho na RP. Odkia\u013e vie, kto je RP? V tomto pr\u00edpade je nastaven\u00fd staticky, a o dynamickom nastaven\u00ed RP si povieme nesk\u00f4r. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP skontroluje, \u010di existovala inform\u00e1cia od niekoho, kto by chcel dost\u00e1va\u0165 tento traffic. Predpokladajme, \u017ee nie. Potom RP po\u0161le R1 spr\u00e1vu PIM Register-Stop, \u010do znamen\u00e1, \u017ee nikto nem\u00e1 z\u00e1ujem o tento multicast, registr\u00e1cia bola zamietnut\u00e1. R1 nebude posiela\u0165 multicast. Ale hostite\u013e zdroja multicastu ho bude posiela\u0165, tak\u017ee R1 po obdr\u017ean\u00ed Register-Stop spust\u00ed \u010dasova\u010d Register-Suppression timer s hodnotou 60 sek\u00fand. 5 sek\u00fand pred uplynut\u00edm tohto \u010dasova\u010da R1 po\u0161le pr\u00e1zdnu Register spr\u00e1vu s Null-Register bit (teda bez zapuzdren\u00e9ho multicast paketu) smerom k RP. RP na svoju stranu zareaguje takto:<\/p>\n<ul>\n<li> Ak pr\u00edjemcov nebolo, tak ani nie je, tak\u017ee odpovie spr\u00e1vou Register-Stop.<\/li>\n<li> Ak sa pr\u00edjemcovia objavia, na spr\u00e1vu nijako nezareaguje. R1, ak v priebehu 5 sek\u00fand nedostane odmietnutie svojej registr\u00e1cie, sa pote\u0161\u00ed a po\u0161le Register spr\u00e1vu so zapuzdren\u00fdm multicastom na RP.<\/li>\n<\/ul>\n<p>\nAko multicast dosahuje RP, zd\u00e1 sa, \u017ee sme si u\u017e objasnili, teraz sa pok\u00fasime odpoveda\u0165 na ot\u00e1zku, ako RP dopravuje traffic k prij\u00edmate\u013eom. Je potrebn\u00e9 zavies\u0165 nov\u00fd pojem \u2014 root-path tree (RPT). RPT je strom s kore\u0148om v RP, rast\u00faci smerom k prij\u00edmate\u013eom, rozvetvuj\u00faci sa na ka\u017edom PIM-SM routeri. RP ho vytv\u00e1ra prij\u00edman\u00edm PIM Join spr\u00e1v a do stromu prid\u00e1va nov\u00fa vetvu. A takto rob\u00ed ka\u017ed\u00fd podraden\u00fd router. V\u0161eobecn\u00e9 pravidlo znie:<\/p>\n<ul>\n<li> Ke\u010f PIM-SM router prijme PIM Join spr\u00e1vu na niektorom rozhran\u00ed, okrem rozhrania, za ktor\u00fdm sa skr\u00fdva RP, prid\u00e1va do stromu nov\u00fa vetvu.<\/li>\n<li> Vetva sa tie\u017e prid\u00e1va, ke\u010f PIM-SM router prijme IGMP Membership Report od priamo pripojen\u00e9ho hosta. <\/li>\n<\/ul>\n<p>\nPredstavme si, \u017ee m\u00e1me klienta multicastu na routeri R5 pre skupinu 228.8.8.8. Hne\u010f ako R5 prijme IGMP Membership Report od hosta, R5 po\u0161le PIM Join smerom k RP a z\u00e1rove\u0148 prid\u00e1 do stromu rozhranie, ktor\u00e9 smeruje k hostu. N\u00e1sledne R4 prijme PIM Join od R5, prid\u00e1 do stromu rozhranie Gi0\/1 a po\u0161le PIM Join smerom k RP. Nakoniec RP (R3) prijme PIM Join a prid\u00e1 Gi0\/0 do stromu. T\u00fdmto vznik\u00e1 registr\u00e1cia prij\u00edmate\u013ea multicastu. Vytv\u00e1rame strom s kore\u0148om R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nPo tomto sa odo\u0161le PIM Join k R1 a R1 za\u010dne posiela\u0165 multicast dopravu. Je d\u00f4le\u017eit\u00e9 poznamena\u0165, \u017ee ak hostite\u013e po\u017eiadal o dopravu pred za\u010diatkom vysielania multicastu, RP neodo\u0161le PIM Join a v\u00f4bec ni\u010d neodo\u0161le smerom k R1.<br \/>\nAk n\u00e1hodou, po\u010das posielania multicastu, hostite\u013e prestane chcie\u0165 ho prij\u00edma\u0165, hne\u010f ako RP dostane PIM Prune na rozhran\u00ed Gi0\/0, okam\u017eite po\u0161le PIM Register-Stop priamo k R1 a potom aj PIM Prune spr\u00e1vu cez rozhranie Gi0\/1. PIM Register-stop sa posiela unicastom na t\u00fa adresu, z ktorej pri\u0161lo PIM Register.<br \/>\nAko sme u\u017e spom\u00ednali, akon\u00e1hle router po\u0161le PIM Join in\u00e9mu, napr\u00edklad R5 na R4, na R4 sa prid\u00e1 z\u00e1znam:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nA spust\u00ed sa \u010dasova\u010d, ktor\u00fd resetuje tento \u010dasova\u010d R5 mus\u00ed neust\u00e1le posiela\u0165 PIM Join spr\u00e1vy, inak R4 vyl\u00fa\u010di z outgoing list. R5 bude posiela\u0165 ka\u017ed\u00fdch 60 sek\u00fand PIM Join spr\u00e1vy.<br \/>\n<b>Prechod na tree s najkrat\u0161ou cestou.<\/b><br \/>\nPrid\u00e1me rozhranie medzi R1 a R5 a pozrieme sa, ako sa bude pren\u00e1\u0161a\u0165 doprava pri takejto topol\u00f3gii. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPredpokladajme, \u017ee doprava sa posielala a prij\u00edmala pod\u013ea starej sch\u00e9my R1-R2-R3-R4-R5 a teraz sme pripojili a nastavili rozhranie medzi R1 a R5.<br \/>\nNajprv sa n\u00e1m prestavia unicastov\u00e1 tabu\u013eka smerovania na R5 a teraz je sie\u0165 192.168.1.0\/24 dostupn\u00e1 cez rozhranie R5 Gi0\/2. Teraz R5, prij\u00edmaj\u00faci multicast na rozhran\u00ed Gi0\/1, ch\u00e1pe, \u017ee pravidlo RPF nie je splnen\u00e9 a bolo by logickej\u0161ie prij\u00edma\u0165 multicast na Gi0\/2. Mus\u00ed sa odpoji\u0165 od RPT a postavi\u0165 krat\u0161\u00ed strom, ktor\u00fd sa naz\u00fdva Shortest-Path Tree (SPT). Na to cez Gi0\/2 odosiela PIM Join k R1 a R1 za\u010dne posiela\u0165 multicast aj cez Gi0\/2. Teraz sa R5 mus\u00ed odhl\u00e1si\u0165 od RPT, aby neprij\u00edmal dve k\u00f3pie. Na to posiela Prune spr\u00e1vu so \u0161pecifickou IP adresou zdroja a vklad\u00e1 \u0161peci\u00e1lny bit \u2014 RPT-bit. To znamen\u00e1, \u017ee mi nem\u00f4\u017eete posiela\u0165 dopravu, m\u00e1m tu lep\u0161\u00ed strom. RP tie\u017e posiela smerom k R1 PIM Prune spr\u00e1vy, ale neodosiela Register-Stop spr\u00e1vu. \u010eal\u0161\u00edm \u0161peci\u00e1lnym rysom je, \u017ee R5 teraz neust\u00e1le posiela PIM Prune k RP, ke\u010f\u017ee R1 na\u010falej posiela PIM Register k RP ka\u017ed\u00fa min\u00fatu. K\u00fdm nebud\u00fa nov\u00ed z\u00e1ujemcovia o t\u00fato dopravu, bude RP odpoveda\u0165 odmietnut\u00edm. R5 informuje RP, \u017ee na\u010falej prij\u00edma multicast cez SPT.<br \/>\n<b>Dynamick\u00e9 vyh\u013ead\u00e1vanie RP. <br \/>\nAuto-RP.<\/b><br \/>\nT\u00e1to technol\u00f3gia je propriet\u00e1rna od spolo\u010dnosti Cisco a nie je pr\u00edli\u0161 popul\u00e1rna, ale st\u00e1le pre\u017e\u00edva. \u010cinnos\u0165 Auto-RP pozost\u00e1va z dvoch hlavn\u00fdch et\u00e1p:<br \/>\n1) RP posiela RP-Announce spr\u00e1vy na rezervovan\u00fa adresu \u2014 224.0.1.39, oznamuj\u00fac sa ako RP bu\u010f pre v\u0161etk\u00fdch, alebo pre ur\u010dit\u00e9 skupiny. Spr\u00e1va sa odosiela ka\u017ed\u00fa min\u00fatu.<br \/>\n2) Je potrebn\u00fd RP mapping agent, ktor\u00fd bude posiela\u0165 RP-Discovery spr\u00e1vy s inform\u00e1ciou, pre ktor\u00e9 skupiny je potrebn\u00e9 po\u010d\u00fava\u0165 ktor\u00e9ho RP. Pr\u00e1ve z tejto spr\u00e1vy zvy\u010dajn\u00e9 PIM smerova\u010de ur\u010dia, ktor\u00fd RP si maj\u00fa zvoli\u0165. Mapping agent m\u00f4\u017ee by\u0165 bu\u010f samotn\u00fd RP smerova\u010d, alebo ak\u00fdko\u013evek in\u00fd samostatn\u00fd PIM smerova\u010d. RP-Discovery sa posiela na adresu 224.0.1.40 s \u010dasova\u010dom jedna min\u00fata.<br \/>\nPozrime sa na proces podrobnej\u0161ie:<br \/>\nNastav\u00edme R3 ako RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 ako mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nA na v\u0161etk\u00fdch ostatn\u00fdch budeme \u010daka\u0165 na RP cez Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nAkon\u00e1hle nastav\u00edme R3, za\u010dne odosiela\u0165 RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nA R2, po nastaven\u00ed ako mapping agent, za\u010dne \u010daka\u0165 na spr\u00e1vy RP-Announce. Iba ke\u010f n\u00e1jde aspo\u0148 jeden RP, za\u010dne odosiela\u0165 RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nT\u00fdmto sp\u00f4sobom, akon\u00e1hle oby\u010dajn\u00e9 smerova\u010de (PIM RP Listener) dostan\u00fa t\u00fato spr\u00e1vu, bud\u00fa vedie\u0165, kde h\u013eada\u0165 RP.<br \/>\nJedn\u00fdm z hlavn\u00fdch probl\u00e9mov Auto-RP je, \u017ee na prij\u00edmanie spr\u00e1v RP-Announce a RP-Discovery je potrebn\u00e9 odosla\u0165 PIM Join na adresy 224.0.1.39-40, a na to, aby sa mohlo odesla\u0165, je potrebn\u00e9 vedie\u0165, kde sa nach\u00e1dza RP. Klasick\u00fd probl\u00e9m sliepky a vajca. Na rie\u0161enie tohto probl\u00e9mu bol navrhnut\u00fd re\u017eim PIM Sparse-Dense-Mode. Ak smerova\u010d nepozn\u00e1 RP, funguje v re\u017eime Dense-mode, ak pozn\u00e1, tak v re\u017eime Sparse-mode. Ke\u010f s\u00fa na rozhran\u00ed oby\u010dajn\u00fdch smerova\u010dov nastaven\u00e9 PIM Sparse-mode a pr\u00edkaz ip pim autorp listener, smerova\u010d bude fungova\u0165 v Dense-mode iba pre multicast Auto-RP protokolu (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nT\u00e1to funkcia funguje podobne ako Auto-RP. Ka\u017ed\u00fd RP posiela spr\u00e1vu mapping agentovi, ktor\u00fd zhroma\u017e\u010fuje mapovacie inform\u00e1cie a potom ich odovzd\u00e1va v\u0161etk\u00fdm ostatn\u00fdm smerova\u010dom. Proces op\u00ed\u0161eme podobne ako Auto-RP:<br \/>\n1) Akon\u00e1hle nastav\u00edme R3 za kandid\u00e1ta na RP, pr\u00edkazom:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nR3 ni\u010d neurob\u00ed, aby za\u010dal posiela\u0165 \u0161peci\u00e1lne spr\u00e1vy, najprv mus\u00ed n\u00e1js\u0165 mapping agenta. Tak sa posunieme k druh\u00e9mu kroku.<br \/>\n2) Nastav\u00edme R2 ako mapping agent:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 za\u010dne rozosiela\u0165 PIM Bootstrap spr\u00e1vy, kde se ozna\u010duje ako mapping agent:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nToto hl\u00e1senie je odosielan\u00e9 na adresu 224.0.0.13, ktor\u00fa PIM protokol pou\u017e\u00edva aj pre in\u00e9 svoje spr\u00e1vy. Odes\u00edlaj\u00ed se do v\u0161etk\u00fdch smerov, a preto nie je probl\u00e9m s kur\u010datami a vajcami, ako to bolo pri Auto-RP.<br \/>\n3) Akon\u00e1hle RP dostane spr\u00e1vu od BSR smerova\u010da, okam\u017eite ode\u0161le unicastov\u00fa spr\u00e1vu na adresu BSR smerova\u010da:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPotom, \u010do BSR dostane inform\u00e1cie o RP, rozosiela ich multicastom na adresu 224.0.0.13, ktor\u00fa po\u010d\u00favaj\u00fa v\u0161etci PIM smerova\u010de. Preto neexistuje ekvivalent pr\u00edkazu <i>ip pim autorp listener<\/i> pre be\u017en\u00e9 smerova\u010de v BSR.<br \/>\n<b>Anycast RP s Multicast Source Discovery Protocol (MSDP).<\/b><br \/>\nAuto-RP a BSR n\u00e1m umo\u017e\u0148uj\u00fa rozlo\u017ei\u0165 z\u00e1\u0165a\u017e na RP nasledovne: Ka\u017ed\u00e1 multicast skupina m\u00e1 iba jedno akt\u00edvne RP. Nepodar\u00ed sa rozlo\u017ei\u0165 z\u00e1\u0165a\u017e pre jednu multicast skupinu na nieko\u013eko RP. MSDP to rob\u00ed pomocou pride\u013eovania RP smerova\u010dom rovnak\u00fa IP adresu s maskou 255.255.255.255. MSDP z\u00edskava inform\u00e1cie jedn\u00fdm z met\u00f3d: staticky, Auto-RP alebo BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNa obr\u00e1zku m\u00e1me Auto-RP konfigur\u00e1ciu s MSDP. Obe RP s\u00fa nastaven\u00e9 s IP adresou 172.16.1.1\/32 na Loopback 1 rozhran\u00ed a pou\u017e\u00edvaj\u00fa sa pre v\u0161etky skupiny. Pri RP-Announce obidva smerova\u010de hovoria o sebe, odvol\u00e1vaj\u00fac sa na t\u00fato adresu. Auto-RP mapping agent, z\u00edskavuj\u00fac inform\u00e1cie, rozosiela RP-Discovery o RP s adresou 172.16.1.1\/32. O sieti 172.16.1.1\/32 hovor\u00edme smerova\u010dom pomocou IGP a, samozrejme. Takto PIM smerova\u010de po\u017eaduj\u00fa alebo registruj\u00fa toky od toho RP, ktor\u00fd je uveden\u00fd ako next-hop v trase k sieti 172.16.1.1\/32. Samotn\u00fd protokol MSDP je ur\u010den\u00fd pre RP, aby si vymenili spr\u00e1vy o inform\u00e1ci\u00e1ch o multicast.<br \/>\nZv\u00e1\u017eme tak\u00fato topol\u00f3giu:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpy fungovania protokolu PIM\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 vysiela prenos na adresu 238.38.38.38 a zatia\u013e o \u0148om vie iba RP-R1. Tu Switch7 a Switch8 po\u017eiadali o t\u00fato skupinu. Smerova\u010de R5 a R4 odo\u0161l\u00fa PIM Join na R1 a R3, pr\u00edslu\u0161ne. Pre\u010do? Trasa k 13.13.13.13 u R5 bude odkazova\u0165 na R1 pod\u013ea metriky IGP, rovnako ako u R4.<br \/>\nRP-R1 vie o toku a za\u010dne ho vysiela\u0165 smerom k R5, ale R4 o \u0148om ni\u010d nevie, preto\u017ee R1 ho jednoducho takto posiela\u0165 nebude. Preto je potrebn\u00fd MSDP. Nastav\u00edme ho na R1 a R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 na R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 na R3<\/p><\/blockquote>\n<p>\nOni nadvia\u017eu rel\u00e1ciu medzi sebou a pri prij\u00edman\u00ed ak\u00e9hoko\u013evek toku bud\u00fa informova\u0165 o \u0148om svojho RP suseda.<br \/>\nKe\u010f RP-R1 z\u00edska pr\u00fad zo Switch6, okam\u017eite po\u0161le unikastom spr\u00e1vu MSDP Source-Active, ktor\u00e1 bude obsahova\u0165 inform\u00e1cie typu (S, G) \u2014 inform\u00e1cie o zdroji a ur\u010denia multicastu. Teraz, ke\u010f RP-R3 vie, \u017ee existuje zdroj ako Switch6, pri prijat\u00ed po\u017eiadavky od R4 na tento pr\u00fad, po\u0161le smerom k Switch6 PIM Join pod\u013ea smerovacej tabu\u013eky. T\u00fdm p\u00e1dom, ak R1 prijme tak\u00fd PIM Join, za\u010dne posiela\u0165 prev\u00e1dzku smerom k RP-R3.<br \/>\nMSDP funguje cez TCP, RP si navz\u00e1jom posielaj\u00fa keepalive spr\u00e1vy na overenie \u017eivotaschopnosti. \u010casova\u010d je nastaven\u00fd na 60 sek\u00fand.<br \/>\nFunkcia rozde\u013eovania MSDP peerov do r\u00f4znych dom\u00e9n zost\u00e1va nejasn\u00e1, preto\u017ee v spr\u00e1vach keepalive a SA nie je uveden\u00e1 pr\u00edslu\u0161nos\u0165 k \u017eiadnej dom\u00e9ne. V tejto topol\u00f3gii bola testovan\u00e1 aj konfigur\u00e1cia s uveden\u00edm r\u00f4znych dom\u00e9n \u2014 rozdiel v prev\u00e1dzke nebol. <br \/>\nAk niekto m\u00f4\u017ee objasni\u0165, s rados\u0165ou si pre\u010d\u00edtam v koment\u00e1roch.<br \/>\n<br \/>Zdroj: <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.3 - 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\/sk\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\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\/sk\/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\udd47Princ\u00edpy fungovania protokolu PIM | ProHoster","description":"Protokol PIM je s\u00fabor protokolov na prenos multicastu v sie\u0165ach medzi smerova\u010dmi. Vz\u0165ahy susedstva sa buduj\u00fa podobne ako v pr\u00edpade dynamick\u00fdch smerovac\u00edch protokolov.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}