{"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\/pl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Zasady dzia\u0142ania protoko\u0142u PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Protok\u00f3\u0142 PIM to zestaw protoko\u0142\u00f3w do przesy\u0142ania multicastu w sieci pomi\u0119dzy routerami. Relacje s\u0105siedztwa budowane s\u0105 analogicznie jak w przypadku dynamicznych protoko\u0142\u00f3w routingu. PIMv2 wysy\u0142a co 30 sekund wiadomo\u015bci Hello na zarezerwowany adres multicast 224.0.0.13 (All-PIM-Routers). Wiadomo\u015b\u0107 zawiera Hold Timers \u2013 zazwyczaj r\u00f3wny 3,5 * Hello Timer, czyli 105 sekund domy\u015blnie.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM korzysta z dw\u00f3ch podstawowych tryb\u00f3w pracy \u2013 Dense i Sparse mode. Zacznijmy od Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Source-Based Distribution Trees.<\/b><br \/>\nTryb Dense mode warto stosowa\u0107 w przypadku du\u017cej liczby klient\u00f3w r\u00f3\u017cnych grup multicastowych. Gdy router odbiera ruch multicastowy, przede wszystkim sprawdza go pod k\u0105tem regu\u0142y RPF. RPF \u2013 ta regu\u0142a jest u\u017cywana do weryfikacji \u017ar\u00f3d\u0142a multicastu z unicastow\u0105 tabel\u0105 routingu. Ruch musi przychodzi\u0107 na ten interfejs, za kt\u00f3rym kryje si\u0119 dany host wed\u0142ug wersji unicastowej tabeli routingu. Mechanizm ten rozwi\u0105zuje problem pojawiania si\u0119 p\u0119tli podczas przesy\u0142ania multicastu.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nRouter R3 z wiadomo\u015bci multicastowej dowiaduje si\u0119 o \u017ar\u00f3dle multicastu (Source IP) i sprawdzi dwa strumienie od R1 i R2 w swojej tabeli unicastowej. Strumie\u0144 z tego interfejsu, na kt\u00f3ry wskazuje tabela (R1 do R3), zostanie przekazany dalej, a strumie\u0144 od R2 zostanie odrzucony, poniewa\u017c aby dotrze\u0107 do \u017ar\u00f3d\u0142a multicastu, nale\u017cy wysy\u0142a\u0107 pakiety przez S0\/1.<br \/>\nPytanie, co si\u0119 stanie, je\u015bli macie dwa r\u00f3wnowa\u017cne trasy z tak\u0105 sam\u0105 metryk\u0105? W takim przypadku router wybierze na podstawie next-hop tych tras. Kto ma wy\u017cszy adres IP, ten wygrywa. Je\u015bli trzeba zmieni\u0107 to zachowanie, mo\u017cna zastosowa\u0107 ECMP. Wi\u0119cej informacji <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">tutaj<\/a><\/noindex>.<br \/>\nPo weryfikacji regu\u0142y RPF, router wysy\u0142a pakiet multicastowy do wszystkich swoich s\u0105siad\u00f3w PIM, z wyj\u0105tkiem tego, od kt\u00f3rego otrzyma\u0142 dany pakiet. Pozosta\u0142e routery PIM powtarzaj\u0105 ten proces. Droga, kt\u00f3r\u0105 przeby\u0142 pakiet multicastowy od \u017ar\u00f3d\u0142a do ostatecznych odbiorc\u00f3w, tworzy drzewo nazywane \u2013 source-based distribution tree, shortest-path tree (SPT), source tree. Trzy r\u00f3\u017cne nazwy, wybierz dowoln\u0105 z nich.<br \/>\nJak rozwi\u0105za\u0107 problem, \u017ce niekt\u00f3re routery nie mog\u0142y odbiera\u0107 pewnego strumienia multicastowego i nie maj\u0105 do kogo go wys\u0142a\u0107, podczas gdy wysy\u0142a go wy\u017cszy router? Dla tego stworzono mechanizm Prune. <br \/>\n<b>Prune Message.<\/b><br \/>\nNa przyk\u0142ad, R2 b\u0119dzie kontynuowa\u0142 wysy\u0142anie R3 multicast, mimo \u017ce R3 odrzuca go zgodnie z zasad\u0105 RPF. Po co obci\u0105\u017ca\u0107 kana\u0142? R3 wysy\u0142a wiadomo\u015b\u0107 PIM Prune, a R2 po otrzymaniu tej wiadomo\u015bci usunie interfejs S0\/1 z listy (outgoing interface list) dla tego strumienia, czyli listy interfejs\u00f3w, z kt\u00f3rych nale\u017cy wysy\u0142a\u0107 ten ruch. <\/p>\n<blockquote><p>Poni\u017cej znajduje si\u0119 bardziej formalna definicja wiadomo\u015bci PIM Prune:<br \/>\nWiadomo\u015b\u0107 PIM Prune jest wysy\u0142ana przez jeden router do drugiego routera, aby spowodowa\u0107, \u017ce drugi router usunie \u0142\u0105cze, na kt\u00f3rym odebrano Prune, z okre\u015blonego (S,G) SPT.<\/p><\/blockquote>\n<p>\nPo otrzymaniu wiadomo\u015bci Prune, R2 ustawia timer Prune na 3 minuty. Po trzech minutach zacznie ponownie wysy\u0142a\u0107 ruch, dop\u00f3ki nie otrzyma kolejnej wiadomo\u015bci Prune. To jest w PIMv1.<br \/>\nA w PIMv2 dodano timer State Refresh (domy\u015blnie 60 sekund). Gdy tylko wys\u0142ano wiadomo\u015b\u0107 Prune z R3, uruchamiany jest ten timer na R3. Po up\u0142ywie tego timera R3 wy\u015ble wiadomo\u015b\u0107 State Refresh, kt\u00f3ra zresetuje 3-minutowy timer Prune na R2 dla tej grupy. <br \/>\nPowody wysy\u0142ania wiadomo\u015bci Prune:<\/p>\n<ul>\n<li> Kiedy pakiet multicast nie przeszed\u0142 walidacji RPF.<\/li>\n<li> Kiedy nie ma lokalnie pod\u0142\u0105czonych klient\u00f3w, kt\u00f3rzy za\u017c\u0105dali grupy multicastowej (IGMP Join) i nie ma s\u0105siad\u00f3w PIM, do kt\u00f3rych mo\u017cna wysy\u0142a\u0107 ruch multicastowy (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Wiadomo\u015b\u0107 Graft.<\/b><br \/>\nZa\u0142\u00f3\u017cmy, \u017ce R3 nie chcia\u0142 ruchu z R2, wys\u0142a\u0142 Prune i otrzymywa\u0142 multicast od R1. Ale nagle, kana\u0142 mi\u0119dzy R1 a R3 si\u0119 zepsu\u0142 i R3 pozosta\u0142 bez multicastu. Mo\u017cna czeka\u0107 3 minuty, a\u017c Prune Timer na R2 wygas\u0142. Czekanie 3 minut jest zbyt d\u0142ugie, aby nie czeka\u0107, musisz wys\u0142a\u0107 wiadomo\u015b\u0107, kt\u00f3ra natychmiast wyprowadzi dany interfejs S0\/1 na R2 z stanu pruned. Tak\u0105 wiadomo\u015bci\u0105 b\u0119dzie wiadomo\u015b\u0107 Graft. Po otrzymaniu wiadomo\u015bci Graft, R2 wy\u015ble odpowied\u017a 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=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPrzyjrzyjmy si\u0119 temu schematowi. R1 nadaje multicast do segmentu z dwoma routerami. R3 odbiera i nadaje ruch, R2 odbiera, ale nie ma nikogo, komu m\u00f3g\u0142by nada\u0107 ruch. Wysy\u0142a wiadomo\u015b\u0107 Prune do R1 w tym segmencie. R1 powinien usun\u0105\u0107 Fa0\/0 z listy i przesta\u0107 nadawa\u0107 w tym segmencie, ale co stanie si\u0119 z R3? A R3 jest w tym samym segmencie, r\u00f3wnie\u017c otrzyma\u0142 t\u0119 wiadomo\u015b\u0107 Prune i zrozumia\u0142 ca\u0142\u0105 tragedi\u0119 sytuacji. Zanim R1 przestanie nadawa\u0107, ustawia timer na 3 sekundy i przestaje nadawa\u0107 po 3 sekundach. 3 sekundy \u2014 tyle czasu ma R3, aby nie straci\u0107 swojego multicastu. Dlatego R3 jak najszybciej wysy\u0142a wiadomo\u015b\u0107 Pim Join dla tej grupy, a R1 ju\u017c nie my\u015bli o zaprzestaniu nadawania. O wiadomo\u015bciach Join poni\u017cej.<br \/>\n<b>Wiadomo\u015b\u0107 Assert.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nWyobra\u017amy sobie tak\u0105 sytuacj\u0119: do jednej sieci nadaj\u0105 od razu dwa routery. Odbieraj\u0105 ten sam strumie\u0144 z \u017ar\u00f3d\u0142a, a obydwa nadaj\u0105 go do jednej sieci za interfejsem e0. Dlatego musz\u0105 ustali\u0107, kto b\u0119dzie jednym jedynym nadawc\u0105 dla tej sieci. Do tego s\u0142u\u017c\u0105 wiadomo\u015bci Assert. Kiedy R2 i R3 wykrywaj\u0105 duplikacj\u0119 ruchu multicast, to znaczy, \u017ce na R2 i R3 przychodzi multicast, kt\u00f3ry sami nadaj\u0105, routery rozumiej\u0105, \u017ce co\u015b jest nie tak. W takiej sytuacji routery wysy\u0142aj\u0105 wiadomo\u015bci Assert, kt\u00f3re zawieraj\u0105 Administrative Distance oraz metryk\u0119 trasy, za pomoc\u0105 kt\u00f3rej osi\u0105gany jest \u017ar\u00f3d\u0142o multicastu \u2014 10.1.1.10. Zwyci\u0119zca jest okre\u015blany w ten spos\u00f3b:<\/p>\n<ol>\n<li>Ten, kto ma ni\u017csze AD.<\/li>\n<li>Je\u017celi AD s\u0105 r\u00f3wne, to ten, kto ma ni\u017csz\u0105 metryk\u0119.<\/li>\n<li>Je\u017celi i tutaj jest r\u00f3wno\u015b\u0107, to ten, kto ma wy\u017cszy adres IP w sieci, do kt\u00f3rej nadaj\u0105 ten multicast.<\/li>\n<\/ol>\n<p>\nZwyci\u0119zca tego g\u0142osowania, router staje si\u0119 Designated Routerem. Do wyboru DR r\u00f3wnie\u017c u\u017cywa si\u0119 PIM Hello. Na pocz\u0105tku artyku\u0142u pokazano wiadomo\u015b\u0107 PIM Hello, mo\u017cna zauwa\u017cy\u0107 pole DR. Zwyci\u0119\u017ca ten, kto ma wy\u017csze adresy IP na tym \u0142\u0105czu.<br \/>\nPrzydatna tabelka:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>Tabela MROUTE.<\/b><br \/>\nPo wst\u0119pnym zapoznaniu si\u0119 z dzia\u0142aniem protoko\u0142u PIM, musimy zrozumie\u0107, jak dzia\u0142a tabela routingu multicast. W tabeli mroute przechowywane s\u0105 informacje o tym, jakie strumienie zosta\u0142y za\u017c\u0105dane przez klient\u00f3w i jakie strumienie sp\u0142ywaj\u0105 z serwer\u00f3w multicastowych. <br \/>\nNa przyk\u0142ad, po otrzymaniu raportu IGMP Membership Report lub PIM Join na jakim\u015b interfejsie, do tabeli routingu dodawany jest wpis typu (*, G):<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nTen wpis oznacza, \u017ce otrzymano zapytanie o ruch z adresu 238.38.38.38. Flaga DC oznacza, \u017ce multicast b\u0119dzie dzia\u0142a\u0107 w trybie Dense mode, a S oznacza, \u017ce odbiorca jest bezpo\u015brednio pod\u0142\u0105czony do routera, to znaczy, \u017ce router otrzyma\u0142 raport cz\u0142onkostwa IGMP, a PIM Join.<br \/>\nJe\u015bli istnieje wpis typu (S,G), oznacza to, \u017ce mamy strumie\u0144 multicast:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nW polu S \u2014 192.168.1.11, mamy zapisany adres IP \u017ar\u00f3d\u0142a multicastu, to on b\u0119dzie sprawdzany regu\u0142\u0105 RPF. W przypadku problem\u00f3w, najpierw nale\u017cy sprawdzi\u0107 tabel\u0119 unicastow\u0105 pod k\u0105tem trasy do \u017ar\u00f3d\u0142a. W polu Incoming Interface wskazuje interfejs, na kt\u00f3ry przychodzi multicast. W tabeli trasowania unicastowego, trasa do \u017ar\u00f3d\u0142a powinna odnosi\u0107 si\u0119 do interfejsu wskazanego tutaj. W Outgoing Interface wskazuje, gdzie multicast zostanie przekierowany. Je\u015bli jest pusty, oznacza to, \u017ce do routera nie wp\u0142ywa\u0142y \u017cadne zapytania o ten ruch. Bardziej szczeg\u00f3\u0142owe informacje o wszystkich flagach mo\u017cna znale\u017a\u0107. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">tutaj<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nStrategia Sparse-mode jest odwrotno\u015bci\u0105 Dense-mode. Gdy Sparse-mode otrzymuje ruch multicastowy, b\u0119dzie wysy\u0142a\u0107 ruch tylko przez te interfejsy, gdzie by\u0142y zapytania o ten strumie\u0144, na przyk\u0142ad wiadomo\u015bci Pim Join lub raporty IGMP z zapytaniem o ten ruch.<br \/>\nPodobne elementy w SM i DM:<\/p>\n<ul>\n<li> Relacje s\u0105siedztwa s\u0105 budowane tak samo, jak w PIM DM.<\/li>\n<li> Regu\u0142a RPF dzia\u0142a.<\/li>\n<li> Wyb\u00f3r DR jest analogiczny.<\/li>\n<li> Mechanizm Prune Overrides i komunikaty Assert s\u0105 podobne.<\/li>\n<\/ul>\n<p>\nAby kontrolowa\u0107, \u043a\u043e\u043c\u0443, gdzie i jaki ruch multicastowy jest potrzebny w sieci, potrzebne jest wsp\u00f3lne centrum informacyjne. Takim centrum b\u0119dzie Rendezvous Point (RP). Wszyscy, kt\u00f3rzy chc\u0105 otrzyma\u0107 jaki\u015b ruch multicastowy lub kt\u00f3rzy zacz\u0119li otrzymywa\u0107 ruch multicastowy ze \u017ar\u00f3d\u0142a, wysy\u0142aj\u0105 go do RP.<br \/>\nGdy RP otrzyma ruch multicastowy, wy\u015ble go tym routerom, kt\u00f3re wcze\u015bniej prosi\u0142y o ten ruch. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nZa\u0142\u00f3\u017cmy tak\u0105 topologi\u0119, gdzie RP to R3. Gdy tylko R1 otrzyma ruch od S1, encapsuluje ten pakiet multicastowy w wiadomo\u015bci PIM Register typu unicast i wysy\u0142a go do RP. Sk\u0105d wie, kto to RP? W tym przypadku jest skonfigurowany statycznie, a o dynamicznej konfiguracji RP porozmawiamy p\u00f3\u017aniej. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP sprawdzi, czy by\u0142a jaka\u015b informacja od kogo\u015b, kto chcia\u0142by otrzymywa\u0107 ten ruch? Za\u0142\u00f3\u017cmy, \u017ce nie by\u0142o. Wtedy RP wy\u015ble do R1 wiadomo\u015b\u0107 PIM Register-Stop, co oznacza, \u017ce nikt nie potrzebuje tego multicastu, rejestracja zosta\u0142a odrzucona. R1 nie b\u0119dzie wysy\u0142a\u0107 multicastu. Jednak \u017ar\u00f3d\u0142o hosta multicastu b\u0119dzie go wysy\u0142a\u0107, wi\u0119c R1 po otrzymaniu Register-Stop uruchomi timer Register-Suppression, r\u00f3wny 60 sekundom. Na 5 sekund przed up\u0142ywem tego timera, R1 wy\u015ble pust\u0105 wiadomo\u015b\u0107 Register z bitem Null-Register (tj. bez kapsu\u0142kowanej paczki multicastowej) w kierunku RP. RP z kolei zadzia\u0142a w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n<ul>\n<li> Je\u015bli odbiorc\u00f3w nie by\u0142o i nadal nie ma, to odpowie wiadomo\u015bci\u0105 Register-Stop.<\/li>\n<li> Je\u015bli odbiorcy si\u0119 pojawi\u0105, to w og\u00f3le na ni\u0105 nie odpowie. R1, nie otrzymawszy odmowy dla swojej rejestracji w ci\u0105gu 5 sekund, ucieszy si\u0119 i wy\u015ble wiadomo\u015b\u0107 Register z kapsu\u0142kowanym multicastem do RP.<\/li>\n<\/ul>\n<p>\nJu\u017c ustalili\u015bmy, jak multicast dociera do RP, teraz spr\u00f3bujmy odpowiedzie\u0107 na pytanie, jak RP dostarcza ruch do odbiorc\u00f3w. Tutaj trzeba wprowadzi\u0107 nowe poj\u0119cie \u2014 drzewo \u015bcie\u017cki \u017ar\u00f3d\u0142owej (RPT). RPT to drzewo z korzeniem w RP, rozrastaj\u0105ce si\u0119 w kierunku odbiorc\u00f3w, rozga\u0142\u0119ziaj\u0105ce si\u0119 na ka\u017cdym routerze PIM-SM. RP tworzy je, otrzymuj\u0105c wiadomo\u015bci PIM Join i dodaje now\u0105 ga\u0142\u0105\u017a do drzewa. I tak robi ka\u017cdy ni\u017cej stoj\u0105cy router. Og\u00f3lna zasada wygl\u0105da nast\u0119puj\u0105co:<\/p>\n<ul>\n<li> Gdy router PIM-SM otrzymuje wiadomo\u015b\u0107 PIM Join na jakimkolwiek interfejsie, z wyj\u0105tkiem interfejsu, za kt\u00f3rym kryje si\u0119 RP, dodaje now\u0105 ga\u0142\u0105\u017a do drzewa.<\/li>\n<li> Ga\u0142\u0105\u017a jest r\u00f3wnie\u017c dodawana, gdy router PIM-SM otrzymuje raport o cz\u0142onkostwie IGMP od bezpo\u015brednio pod\u0142\u0105czonego hosta. <\/li>\n<\/ul>\n<p>\nZa\u0142\u00f3\u017cmy, \u017ce mamy klienta multicastowego na routerze R5 dla grupy 228.8.8.8. Gdy tylko R5 otrzyma raport o cz\u0142onkostwie IGMP od hosta, R5 wysy\u0142a PIM Join w kierunku RP, a sam dodaje do drzewa interfejs patrz\u0105cy na hosta. Nast\u0119pnie R4 otrzymuje PIM Join od R5, dodaje do drzewa interfejs Gi0\/1 i wysy\u0142a PIM Join w kierunku RP. W ko\u0144cu RP (R3) otrzymuje PIM Join i dodaje Gi0\/0 do drzewa. W ten spos\u00f3b nast\u0119puje rejestracja odbiorcy multicastu. Budujemy drzewo z korzeniem R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nPo tym, zostanie wys\u0142any PIM Join do R1, a R1 zacznie przesy\u0142a\u0107 ruch multicastowy. Wa\u017cne jest, aby zauwa\u017cy\u0107, \u017ce je\u015bli host za\u017c\u0105da\u0142 ruchu przed rozpocz\u0119ciem transmisji multicastu, to RP nie wy\u015ble PIM Join i w og\u00f3le nie wy\u015ble nic w kierunku R1.<br \/>\nJe\u015bli w mi\u0119dzyczasie, podczas przesy\u0142ania multicastu, host przestanie chcie\u0107 go otrzymywa\u0107, gdy tylko RP otrzyma PIM Prune na interfejsie Gi0\/0, natychmiast wy\u015ble PIM Register-Stop bezpo\u015brednio do R1, a nast\u0119pnie wiadomo\u015b\u0107 PIM Prune przez interfejs Gi0\/1. PIM Register-stop jest wysy\u0142any jako unicast na ten adres, z kt\u00f3rego otrzymano PIM Register.<br \/>\nJak ju\u017c wcze\u015bniej wspomnieli\u015bmy, gdy router wysy\u0142a PIM Join do innego, na przyk\u0142ad R5 do R4, to na R4 zostaje dodany wpis:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nI uruchamia si\u0119 timer, w kt\u00f3rym R5 musi stale wysy\u0142a\u0107 PIM Join, w przeciwnym razie R4 wykluczy go z listy outgoing. R5 b\u0119dzie wysy\u0142a\u0107 PIM Join co 60 sekund.<br \/>\n<b>Switchover Shortest-Path Tree.<\/b><br \/>\nDodamy interfejs mi\u0119dzy R1 a R5, aby zobaczy\u0107, jak b\u0119dzie p\u0142yn\u0105\u0107 ruch przy tej topologii. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nZa\u0142\u00f3\u017cmy, \u017ce ruch by\u0142 przesy\u0142any i odbierany wed\u0142ug starego schematu R1-R2-R3-R4-R5, a nast\u0119pnie pod\u0142\u0105czyli\u015bmy i skonfigurowali\u015bmy interfejs mi\u0119dzy R1 a R5.<br \/>\nPo pierwsze, tabela trasowania unicast na R5 zostanie przebudowana i teraz sie\u0107 192.168.1.0\/24 jest osi\u0105gana przez interfejs R5 Gi0\/2. Teraz, gdy R5 odbiera multicast na interfejsie Gi0\/1, zdaje sobie spraw\u0119, \u017ce zasada RPF nie jest spe\u0142niona i lepiej b\u0119dzie otrzyma\u0107 multicast na Gi0\/2. Musi od\u0142\u0105czy\u0107 si\u0119 od RPT i zbudowa\u0107 kr\u00f3tsze drzewo, kt\u00f3re nazywa si\u0119 Shortest-Path Tree (SPT). W tym celu wysy\u0142a PIM Join przez Gi0\/2 do R1, a R1 zaczyna r\u00f3wnie\u017c przesy\u0142a\u0107 multicast przez Gi0\/2. Teraz R5 musi wypisa\u0107 si\u0119 z RPT, aby nie otrzymywa\u0107 dw\u00f3ch kopii. Dlatego wysy\u0142a wiadomo\u015b\u0107 Prune, wskazuj\u0105c adres IP \u017ar\u00f3d\u0142a i wstawiaj\u0105c specjalny bit \u2014 RPT-bit. Oznacza to, \u017ce nie musisz mi wysy\u0142a\u0107 ruchu, mam tu lepsze drzewo. RP r\u00f3wnie\u017c wysy\u0142a wiadomo\u015bci PIM Prune w kierunku R1, ale nie wysy\u0142a wiadomo\u015bci Register-Stop. Kolejn\u0105 cech\u0105 jest to, \u017ce R5 b\u0119dzie teraz stale wysy\u0142a\u0107 PIM Prune do RP, poniewa\u017c R1 nadal wysy\u0142a PIM Register do RP co minut\u0119. RP, dop\u00f3ki nie b\u0119dzie nowych zainteresowanych tym ruchem, b\u0119dzie mu odmawia\u0107. R5 informuje RP, \u017ce nadal otrzymuje multicast przez SPT.<br \/>\n<b>Dynamiczne wyszukiwanie RP. <br \/>\nAuto-RP.<\/b><br \/>\nTa technologia jest w\u0142asno\u015bciowa firmy Cisco i nie cieszy si\u0119 zbyt du\u017c\u0105 popularno\u015bci\u0105, ale wci\u0105\u017c funkcjonuje. Dzia\u0142anie Auto-RP sk\u0142ada si\u0119 z dw\u00f3ch g\u0142\u00f3wnych etap\u00f3w:<br \/>\n1) RP wysy\u0142a wiadomo\u015bci RP-Announce na zarezerwowany adres \u2014 224.0.1.39, og\u0142aszaj\u0105c si\u0119 jako RP dla wszystkich grup lub dla okre\u015blonych grup. Wiadomo\u015b\u0107 ta jest wysy\u0142ana co minut\u0119.<br \/>\n2) Potrzebny jest agent mapowania RP, kt\u00f3ry b\u0119dzie wysy\u0142a\u0142 wiadomo\u015bci RP-Discovery z informacj\u0105, dla kt\u00f3rych grup kt\u00f3ry RP nale\u017cy nas\u0142uchiwa\u0107. To w\u0142a\u015bnie z tej wiadomo\u015bci zwyk\u0142e routery PIM b\u0119d\u0105 okre\u015bla\u0107 sw\u00f3j RP. Agent mapowania mo\u017ce by\u0107 zar\u00f3wno samym routerem RP, jak i oddzielnym routerem PIM. RP-Discovery jest wysy\u0142ane na adres 224.0.1.40 z timerem na jedn\u0105 minut\u0119.<br \/>\nPrzyjrzyjmy si\u0119 procesowi bli\u017cej:<br \/>\nSkonfigurujemy R3 jako RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 jako agent mapowania:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nA na pozosta\u0142ych routerach b\u0119dziemy oczekiwa\u0107 RP przez Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nGdy tylko skonfigurujemy R3, zacznie on wysy\u0142a\u0107 RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nA R2 po skonfigurowaniu jako agent mapowania zacznie czeka\u0107 na wiadomo\u015bci RP-Announce. Tylko gdy znajdzie przynajmniej jeden RP, rozpocznie wysy\u0142anie RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nW ten spos\u00f3b, gdy zwyk\u0142e routery (PIM RP Listener) otrzymaj\u0105 te wiadomo\u015bci, b\u0119d\u0105 wiedzia\u0142y, gdzie szuka\u0107 RP.<br \/>\nJednym z g\u0142\u00f3wnych problem\u00f3w Auto-RP jest to, \u017ce aby otrzymywa\u0107 wiadomo\u015bci RP-Announce i RP-Discovery, nale\u017cy wys\u0142a\u0107 PIM Join na adresy 224.0.1.39-40, a aby to zrobi\u0107, trzeba wiedzie\u0107, gdzie znajduje si\u0119 RP. Klasyczny problem kurczaka i jaja. Aby rozwi\u0105za\u0107 ten problem, wymy\u015blono tryb PIM Sparse-Dense-Mode. Je\u015bli router nie zna RP, dzia\u0142a w trybie Dense-mode, je\u015bli zna, przechodzi w tryb Sparse-mode. Gdy na interfejsach zwyk\u0142ych router\u00f3w skonfigurowany jest PIM Sparse-mode oraz polecenie ip pim autorp listener, router b\u0119dzie dzia\u0142a\u0142 w trybie Dense-mode tylko dla multicastu bezpo\u015brednio protoko\u0142u Auto-RP (224.0.1.39-40).<br \/>\n<b>Router BootStrap (BSR).<\/b><br \/>\nFunkcja ta dzia\u0142a podobnie do Auto-RP. Ka\u017cdy RP wysy\u0142a wiadomo\u015b\u0107 do agenta mapowania, kt\u00f3ry zbiera informacje o mapowaniu i nast\u0119pnie przekazuje je wszystkim innym routerom. Opiszmy proces analogicznie do Auto-RP:<br \/>\n1) Gdy tylko skonfigurujemy R3 jako kandydata na RP, u\u017cywaj\u0105c polecenia:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nW\u00f3wczas R3 nie b\u0119dzie nic robi\u0107, aby zacz\u0105\u0107 wysy\u0142a\u0107 specjalne wiadomo\u015bci, musi najpierw znale\u017a\u0107 agenta mapowania. W ten spos\u00f3b przechodzimy do drugiego kroku.<br \/>\n2) Konfigurujemy R2 jako agenta mapowania:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 zaczyna rozsy\u0142a\u0107 wiadomo\u015bci PIM Bootstrap, w kt\u00f3rych wskazuje siebie jako agenta mapowania:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nWiadomo\u015b\u0107 ta jest wysy\u0142ana na adres 224.0.0.13, kt\u00f3ry protok\u00f3\u0142 PIM wykorzystuje tak\u017ce do innych wiadomo\u015bci. Wysy\u0142a je we wszystkie strony, dlatego nie ma problemu z kur\u0105 i jajkiem, jak to mia\u0142o miejsce w Auto-RP.<br \/>\n3) Gdy tylko RP otrzyma wiadomo\u015b\u0107 od routera BSR, natychmiast wy\u015ble wiadomo\u015b\u0107 unicast na adres routera BSR:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPo tym, BSR, otrzymuj\u0105c informacje o RP, rozsy\u0142a je multicast do adresu 224.0.0.13, kt\u00f3ry nas\u0142uchuj\u0105 wszystkie routery PIM. Dlatego te\u017c nie ma odpowiednika komendy <i>ip pim autorp listener<\/i> dla zwyk\u0142ych router\u00f3w w BSR.<br \/>\n<b>Anycast RP z protoko\u0142em Multicast Source Discovery Protocol (MSDP).<\/b><br \/>\nAuto-RP i BSR umo\u017cliwiaj\u0105 nam roz\u0142o\u017cy\u0107 obci\u0105\u017cenie na RP w nast\u0119puj\u0105cy spos\u00f3b: ka\u017cda grupa multicast ma tylko jednego aktywnego RP. Nie mo\u017cna roz\u0142o\u017cy\u0107 obci\u0105\u017cenia dla jednej grupy multicast na kilku RP. MSDP realizuje to, przydzielaj\u0105c routerom RP ten sam adres IP z mask\u0105 255.255.255.255. MSDP uzyskuje informacje jednym z metod: statycznie, Auto-RP lub BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNa obrazku mamy konfiguracj\u0119 Auto-RP z MSDP. Oba RP s\u0105 skonfigurowane z adresem IP 172.16.1.1\/32 na interfejsie Loopback 1 i u\u017cywane s\u0105 dla wszystkich grup. Podczas RP-Announce obie routery informuj\u0105 o sobie, odwo\u0142uj\u0105c si\u0119 do tego adresu. Agent mapowania Auto-RP, otrzymuj\u0105c informacje, rozsy\u0142a RP-Discovery o RP z adresem 172.16.1.1\/32. O sieci 172.16.1.1\/32, informujemy routery za pomoc\u0105 IGP i, odpowiednio. W ten spos\u00f3b routery PIM \u017c\u0105daj\u0105 lub rejestruj\u0105 strumienie od RP, kt\u00f3ry zosta\u0142 wskazany jako next-hop w trasie do sieci 172.16.1.1\/32. Sam protok\u00f3\u0142 MSDP ma na celu umo\u017cliwienie RP wymiany informacji o multicast.<br \/>\nRozwa\u017cmy tak\u0105 topologi\u0119:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Zasady dzia\u0142ania protoko\u0142u PIM\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 emituje ruch na adres 238.38.38.38 i jak na razie zna go tylko RP-R1. Switch7 i Switch8 zapyta\u0142y o t\u0119 grup\u0119. Routery R5 i R4 wy\u015bl\u0105 PIM Join na R1 i R3, odpowiednio. Dlaczego? Trasa do 13.13.13.13 w R5 b\u0119dzie wskazywa\u0142a na R1 z metryk\u0105 IGP, tak samo jak w R4.<br \/>\nRP-R1 zna strumie\u0144 i zacznie go nadawa\u0107 w kierunku R5, a R4 nic o nim nie wie, poniewa\u017c R1 nie wy\u015ble go po prostu. Dlatego potrzebny jest MSDP. Konfigurujemy go na R1 i 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>\nZainicjuj\u0105 sesj\u0119 mi\u0119dzy sob\u0105 i po otrzymaniu jakiegokolwiek strumienia b\u0119d\u0105 informowa\u0107 o nim swojego s\u0105siedniego RP.<br \/>\nGdy RP-R1 otrzyma strumie\u0144 od Switch6, natychmiast wy\u015ble komunikat MSDP Source-Active przez unicast, zawieraj\u0105cy informacje typu (S, G) \u2014 informacje o \u017ar\u00f3dle i docelowym multicastcie. Teraz, gdy RP-R3 b\u0119dzie wiedzia\u0142, \u017ce takim \u017ar\u00f3d\u0142em jest Switch6, w przypadku otrzymania zapytania od R4 o ten strumie\u0144, wy\u015ble w stron\u0119 Switch6 PIM Join, kieruj\u0105c si\u0119 tabel\u0105 routingu. W zwi\u0105zku z tym, R1 otrzymuj\u0105c taki PIM Join, zacznie wysy\u0142a\u0107 ruch w kierunku RP-R3.<br \/>\nMSDP dzia\u0142a na TCP, RP wymieniaj\u0105 mi\u0119dzy sob\u0105 komunikaty keepalive w celu weryfikacji aktywno\u015bci. Timer wynosi 60 sekund.<br \/>\nFunkcja podzia\u0142u peer\u00f3w MSDP na r\u00f3\u017cne domeny pozostaje niejasna, poniewa\u017c w komunikatach Keepalive i SA nie wskazuje si\u0119 przynale\u017cno\u015bci do jakiejkolwiek domeny. W tej topologii testowano r\u00f3wnie\u017c konfiguracj\u0119 z okre\u015bleniem r\u00f3\u017cnych domen \u2014 nie zauwa\u017cono r\u00f3\u017cnicy w dzia\u0142aniu. <br \/>\nJe\u015bli kto\u015b mo\u017ce wprowadzi\u0107 jasno\u015b\u0107, z przyjemno\u015bci\u0105 przeczytam w komentarzach.<br \/>\n<br \/>\u0179r\u00f3d\u0142o: <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.1.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\/pl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\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\/pl\/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\udd47Zasady dzia\u0142ania protoko\u0142u PIM | ProHoster","description":"Protok\u00f3\u0142 PIM to zestaw protoko\u0142\u00f3w do przesy\u0142ania multicastu w sieci mi\u0119dzy routerami. Relacje s\u0105siedztwa budowane s\u0105 podobnie jak w przypadku dynamicznych protoko\u0142\u00f3w routingu.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}