{"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\/sl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Na\u010dela rada PIM protokola","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>PIM \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b je skup protokola za prenos multicast informacija u mre\u017ei izme\u0111u rutera. Veze susedstva se uspostavljaju na sli\u010dan na\u010din kao u slu\u010daju dinami\u010dkih protokola usmeravanja. PIMv2 \u0161alje svakih 30 sekundi Hello poruke na rezervisanu multicast adresu 224.0.0.13 (All-PIM-Routers). Poruka sadr\u017ei Hold Timers - obi\u010dno jednak 3.5*Hello Timer, odnosno 105 sekundi po defaultu.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM koristi dva osnovna re\u017eima rada - Dense i Sparse mode. Po\u010dnimo sa Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Source-Based Distribution Trees.<\/b><br \/>\nDense-mode re\u017eim je prikladno koristiti u slu\u010daju velikog broja klijenata iz razli\u010ditih multicast grupa. Kada ruter primi multicast saobra\u0107aj, prvo proverava pravilo RPF. RPF - ovo pravilo se koristi za proveru izvora multicast-a u tabeli usmeravanja unicast. Saobra\u0107aj treba da dolazi na onaj interfejs na kojem se nalazi dati host prema verziji unicast tabele usmeravanja. Ovaj mehanizam re\u0161ava problem nastanka petlji prilikom prenosa multicast-a.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 iz multicast poruke saznaje izvor multicast-a (Source IP) i proverava dva toka od R1 i R2 u svojoj unicast tabeli. Tok sa onog interfejsa kojem se ukazuje u tabeli (R1 ka R3) bi\u0107e proslije\u0111en dalje, dok \u0107e tok od R2 biti odbijen, po\u0161to je potrebno slati pakete po S0\/1 da bi se do\u0161lo do izvora multicast-a.<br \/>\nPitanje je \u0161ta \u0107e se dogoditi ako imate dva ekvivalentna rute sa istom metrikom? U tom slu\u010daju ruter \u0107e birati prema next-hop ovih ruta. Onaj sa vi\u0161om IP adresom \u0107e pobediti. Ako je potrebno promeniti ovo pona\u0161anje, mo\u017ee se koristiti ECMP. Vi\u0161e informacija. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">tukaj<\/a><\/noindex>.<br \/>\nNakon provere pravila RPF, ruter \u0161alje multicast paket svim svojim PIM susedima, osim onome od kojeg je primio ovaj paket. Ostali PIM ruteri ponavljaju ovaj proces. Put kojim je multicast paket pro\u0161ao od izvora do krajnjih primaoca formira drvo koje se naziva - source-based distribution tree, shortest-path tree (SPT), source tree. Tri razli\u010dita naziva, izaberite bilo koji.<br \/>\nKako re\u0161iti pitanje da neki ruteri nisu primili odre\u0111eni multicast tok i nemaju kome da ga \u0161alju, ali im vi\u0161i ruter \u0161alje. Za ovo je izumljen Prune mehanizam. <br \/>\n<b>Prune Message.<\/b><br \/>\nNa primer, R2 bo nadaljeval s po\u0161iljanjem R3 multicast, \u010deprav R3 v skladu s pravili RPF zavrne to. Zakaj obremenjevati omre\u017eje? R3 po\u0161lje PIM Prune sporo\u010dilo, R2 pa ob prejemu tega sporo\u010dila odstrani vmesnik S0\/1 iz seznama (outgoing interface list) za to stanje, seznam vmesnikov, s katerih je potrebno po\u0161iljati ta promet. <\/p>\n<blockquote><p>Naslednja opredelitev PIM Prune sporo\u010dila je bolj formalna:<br \/>\nPIM Prune sporo\u010dilo po\u0161lje ena usmerjevalnik drugemu usmerjevalniku, da povzro\u010di, da drugi usmerjevalnik odstrani povezavo, na kateri je Prune prejet, iz dolo\u010denega (S,G) SPT.<\/p><\/blockquote>\n<p>\nPo prejetju Prune sporo\u010dila R2 nastavi Prune \u010dasovnik na 3 minute. \u010cez tri minute bo spet za\u010del po\u0161iljati promet, dokler ne prejme naslednjega Prune sporo\u010dila. To velja za PIMv1.<br \/>\nV PIMv2 je dodan State Refresh \u010dasovnik (privzeto 60 sekund). Takoj ko je bilo poslano Prune sporo\u010dilo z R3, se ta \u010dasovnik aktivira na R3. Po poteku tega \u010dasovnika bo R3 poslalo State Refresh sporo\u010dilo, ki bo ponastavilo 3-minutni Prune Timer na R2 za to skupino. <br \/>\nRazlogi za po\u0161iljanje Prune sporo\u010dila:<\/p>\n<ul>\n<li> Ko multicast paket ni prestal RPF preverjanja.<\/li>\n<li> Ko ni lokalno povezanih strank, ki bi zahtevale multicast skupino (IGMP Join) in ni PIM sosedov, katerim bi lahko po\u0161iljali multicast promet (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Graft Message.<\/b><br \/>\nPredstavljajte si, da R3 no\u010de prometa od R2, po\u0161lje Prune in prejemati multicast od R1. Ampak nenadoma je propadla povezava med R1 in R3 in R3 je ostal brez multicast. \u010cakati je treba 3 minute, da Prune Timer na R2 pote\u010de. \u010cakanje 3 minute je dolgo, da bi skraj\u0161ali to, je treba poslati sporo\u010dilo, ki takoj odstrani ta vmesnik S0\/1 na R2 iz pruned stanja. Tako sporo\u010dilo bo Graft sporo\u010dilo. Po prejemu Graft sporo\u010dila bo R2 odgovorilo z 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=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPoglejmo to shemo. R1 oddaja multicast v segment z dvema usmerjevalnikoma. R3 prejme in oddaja promet, R2 ga prejme, vendar mu ni nikogar, da bi oddajal promet. Po\u0161lje Prune sporo\u010dilo R1 v ta segment. R1 mora odstraniti Fa0\/0 s seznama in prenehati oddajati v ta segment, toda kaj bo s R3? R3 je v istem segmentu, prav tako je prejelo to Prune sporo\u010dilo in spoznalo, kako resna je situacija. Preden R1 preneha oddajati, nastavi \u010dasovnik na 3 sekunde in preneha oddajati \u010dez 3 sekunde. 3 sekunde \u2014 ravno toliko \u010dasa ima R3, da ne izgubi svojega multicast-a. Zato R3 \u010dim prej po\u0161lje Pim Join sporo\u010dilo za to skupino in R1 \u017ee ne razmi\u0161lja ve\u010d o prenehanju oddaje. O Join sporo\u010dilih spodaj.<br \/>\n<b>Assert sporo\u010dilo.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPredstavljajmo si tak\u0161no situacijo: v eno omre\u017eje oddajajo kar dva usmerjevalnika. Prejemata isti tok iz vira in oba ga oddajata v eno omre\u017eje preko vmesnika e0. Zato morata dolo\u010diti, kdo bo edini oddajalec za to omre\u017eje. Za to se uporabljajo Assert sporo\u010dila. Ko R2 in R3 zaznata dupliciranje multicast prometa, torej na R2 in R3 pride multicast, ki ga sama oddajata, usmerjevalnika razumeta, da nekaj ne \u0161tima. V takem primeru usmerjevalniki po\u0161ljejo Assert sporo\u010dila, v katerih so vklju\u010deni Administrative Distance in metrika poti, preko katere se dose\u017ee vir multicast-a \u2014 10.1.1.10. Zmagovalec se dolo\u010di na ta na\u010din:<\/p>\n<ol>\n<li>Tisti, ki ima ni\u017eji AD.<\/li>\n<li>\u010ce sta AD enaka, potem tisti, ki ima ni\u017ejo metriko.<\/li>\n<li>\u010ce je tudi tu enakost, potem tisti, ki ima vi\u0161ji IP v omre\u017eju, v katero oddajajo ta multicast.<\/li>\n<\/ol>\n<p>\nZmagovalec tega glasovanja postane Designated Router. Za izbiro DR se uporabljajo tudi Pim Hello. Na za\u010detku \u010dlanka je bilo prikazano PIM Hello sporo\u010dilo, tam lahko opazite DR polje. Zmaga tisti, ki ima vi\u0161je IP naslove na tej povezavi.<br \/>\nKoristen tabelar.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE tabela.<\/b><br \/>\nPo za\u010detnem pregledu delovanja protokola PIM se moramo poglobiti v to, kako delati z multicast tabelo usmerjanja. V mroute tabeli so shranjeni podatki o tem, kateri tokovi so bili zahtevani s strani strank in kateri tokovi te\u010dejo z multicast stre\u017enikov. <br \/>\nNa primer, ob prejemu IGMP Membership Report ali PIM Join na nekem vmesniku se v tabelo usmerjanja doda zapis tipa ( *, G ):<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nTa zapis pomeni, da je bil prejet zahtevek za promet z naslovom 238.38.38.38. Zastavica DC pomeni, da bo multicast deloval v gostotnem na\u010dinu, C pa pomeni, da je sprejemnik neposredno povezan z usmerjevalnikom, kar pomeni, da je usmerjevalnik prejel IGMP Membership Report in PIM Join.<br \/>\n\u010ce obstaja zapis tipa (S,G), to pomeni, da imamo multicast tok:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nV polju S \u2014 192.168.1.11, imamo zapisan IP naslov vira multicast-a, ta bo preverjen s pravilo RPF. V primeru te\u017eav je najprej potrebno preveriti unicast tabelo za pot do vira. V polju Incoming Interface je naveden vmesnik, na katerega prihaja multicast. V unicast usmerjevalni tabeli mora pot do vira kazati na vmesnik, naveden tukaj. V Outgoing Interface pa je navedeno, kam bo multicast preusmerjen. \u010ce je prazno, to pomeni, da do usmerjevalnika niso pri\u0161li zahtevki za ta promet. Ve\u010d informacij o vseh zastavicah lahko najdete <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">ovde<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nStrategija Sparse-mode je nasprotna Dense-mode. Ko Sparse-mode prejme multicast promet, bo po\u0161iljal promet samo preko tistih vmesnikov, kjer so bili zahtevki za ta tok, na primer Pim Join ali IGMP Report sporo\u010dila z zahtevkom za ta promet.<br \/>\nPodobni elementi pri SM in DM:<\/p>\n<ul>\n<li> Sosednje povezave se gradijo enako kot v PIM DM.<\/li>\n<li> Deluje pravilo RPF.<\/li>\n<li> Izbira DR je podobna.<\/li>\n<li> Mehanizem Prune Overrides in sporo\u010dila Assert sta podobna.<\/li>\n<\/ul>\n<p>\nZa nadzor tega, komu, kje in kak\u0161en multicast promet je potreben v omre\u017eju, je potreben skupni informacijski center. Tak center je Rendezvous Point (RP). Vsi, ki \u017eelijo kak\u0161en multicast promet ali prejmejo multicast promet od vira, po\u0161ljejo zahtevo na RP.<br \/>\nKo RP prejme multicast promet, ga po\u0161lje tistim usmerjevalnikom, ki so prej zahtevali ta promet. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPredstavljajmo si to topologijo, kjer je RP R3. Takoj, ko R1 prejme promet od S1, bo inkapsuliral ta multicast paket v unicast PIM Register sporo\u010dilo in ga poslal na RP. Kako ve, kdo je RP? V tem primeru je nastavljen stati\u010dno, o dinami\u010dni nastavitvi RP pa se bomo pogovorili pozneje. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP bo se vpra\u0161al, ali je bila informacija od koga, ki bi \u017eelel prejemati to promet? Predpostavimo, da ne. Takrat bo RP poslal R1 sporo\u010dilo PIM Register-Stop, kar pomeni, da nih\u010de ne potrebuje tega multicast, registracija je zavrnjena. R1 ne bo po\u0161iljal multicast. Ampak gostitelj, ki izvaja multicast, ga bo po\u0161iljal, zato bo R1 po prejemu Register-Stop zagnal \u0161tevec Register-Suppression timer, ki traja 60 sekund. 5 sekund pred iztekom tega \u0161tevca bo R1 poslal prazno Register sporo\u010dilo z Null-Register bit (to pomeni brez vdelanega multicast paketa) proti RP. RP pa bo ukrepal takole:<\/p>\n<ul>\n<li> \u010ce prejemnikov ni bilo, jih ne bo odzvala z Register-Stop sporo\u010dilom.<\/li>\n<li> \u010ce se prejemniki pojavijo, se na to ne bo odzvala. R1, ki v 5 sekundah ne prejme zavrnitve za svojo registracijo, bo vesel in poslal Register sporo\u010dilo z vdelanim multicastom proti RP.<\/li>\n<\/ul>\n<p>\nZdaj smo razumeli, kako multicast pride do RP, poskusimo odgovoriti na vpra\u0161anje, kako RP dostavi promet do prejemnikov. Tu je treba uvesti nov koncept \u2014 root-path tree (RPT). RPT je drevo s korenom v RP, ki raste proti prejemnikom in se razveja na vsakem PIM-SM usmerjevalniku. RP ga ustvari, ko prejme PIM Join sporo\u010dila in doda novo vejo v drevo. In tako stori vsak spodnji usmerjevalnik. Splo\u0161no pravilo je videti takole:<\/p>\n<ul>\n<li> Ko PIM-SM usmerjevalnik prejme PIM Join sporo\u010dilo na katerem koli vmesniku, razen vmesnika, za katerim se skriva RP, doda novo vejo v drevo.<\/li>\n<li> Veja se tudi doda, ko PIM-SM usmerjevalnik prejme IGMP Membership Report z neposredno povezanega gostitelja. <\/li>\n<\/ul>\n<p>\nPredstavljajmo si, da imamo multicast stranko na usmerjevalniku R5 na skupini 228.8.8.8. Takoj ko R5 prejme IGMP Membership Report od gostitelja, R5 po\u0161lje PIM Join v smeri RP in doda v drevo vmesnik, ki gleda na gostitelja. Nato R4 prejme PIM Join od R5, doda v drevo vmesnik Gi0\/1 in po\u0161lje PIM Join v smeri RP. Nazadnje ga RP (R3) prejme PIM Join in doda Gi0\/0 v drevo. Tako dobimo registracijo prejemnika multicast. Gradimo drevo s korenom R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nNato, bo se poslal PIM Join k R1 in R1 bo za\u010del po\u0161iljati multicast promet. Pomembno je omeniti, da, \u010de je gostitelj zahteval promet, preden se je za\u010delo multicast predvajanje, RP ne bo poslal PIM Join in sploh ne bo ni\u010desar poslal proti R1.<br \/>\n\u010ce med po\u0161iljanjem multicast promet neha gostitelj \u017eelel prejemati, takoj ko RP prejme PIM Prune na vmesniku Gi0\/0, bo takoj poslal PIM Register-Stop neposredno na R1, nato pa sporo\u010dilo PIM Prune preko vmesnika Gi0\/1. PIM Register-stop se po\u0161ilja unicast na naslov, od katerega je pri\u0161el PIM Register.<br \/>\nKot smo \u017ee prej omenili, ko usmerjevalnik po\u0161lje PIM Join drugemu, na primer R5 na R4, se na R4 doda vnos:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nIn se za\u017eene \u010dasovnik, ki ga mora R5 neprekinjeno po\u0161iljati PIM Join sporo\u010dila, ali pa bo R4 izklju\u010dil iz outgoing list. R5 bo po\u0161iljal PIM Join sporo\u010dila vsakih 60.<br \/>\n<b>Preklop na Shortest-Path Tree.<\/b><br \/>\nDodali bomo vmesnik med R1 in R5, da vidimo, kako se bo promet pretakal pri tej topologiji. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nRecimo, da je promet potekal po stari shemi R1-R2-R3-R4-R5 in smo tukaj priklju\u010dili in nastavili vmesnik med R1 in R5.<br \/>\nNa za\u010detku se bo na R5 preoblikovala unicast tabela usmerjanja in sedaj se omre\u017eje 192.168.1.0\/24 dose\u017ee preko vmesnika R5 Gi0\/2. Sedaj, ko R5 prejema multicast na vmesniku Gi0\/1, razume, da pravilo RPF ni zadovoljeno in da bi bilo logi\u010dneje prejemati multicast na Gi0\/2. Moral bi se odjaviti iz RPT in zgraditi kraj\u0161e drevo, ki se imenuje Shortest-Path Tree (SPT). Za to po\u0161lje preko Gi0\/2 PIM Join na R1 in R1 za\u010dne po\u0161iljati multicast tudi preko Gi0\/2. Zdaj se mora R5 odjaviti iz RPT, da ne prejema dveh kopij. Za to po\u0161lje sporo\u010dilo Prune, ozna\u010duje naslov ip vira in vstavlja poseben bit - RPT-bit. To pomeni, da mi ne po\u0161iljajte prometa, imam tukaj bolj\u0161e drevo. RP tudi po\u0161ilja PIM Prune sporo\u010dila proti R1, vendar ne po\u0161ilja Register-Stop sporo\u010dila. \u0160e ena zna\u010dilnost: R5 bo zdaj stalno poslal PIM Prune na RP, saj R1 \u0161e naprej po\u0161ilja PIM Register na RP vsakih minut. Dokler ne bo novih zanimanja za ta promet, bo RP odgovarjal z zavrnitvijo. R5 obve\u0161\u010da RP, da \u0161e naprej prejema multicast preko SPT.<br \/>\n<b>Dinami\u010dno iskanje RP. <br \/>\nAuto-RP.<\/b><br \/>\nTehnologija je lastni\u0161ka od Cisco in ni posebej priljubljena, a \u0161e vedno obstaja. Delo Auto-RP temelji na dveh glavnih korakih:<br \/>\n1) RP po\u0161ilja RP-Announce sporo\u010dila na rezerviran naslov \u2014 224.0.1.39, deklarirajo\u010d sebe kot RP bodisi za vse bodisi za dolo\u010dene skupine. To sporo\u010dilo se po\u0161ilja vsakih minut.<br \/>\n2) Potreben je RP mapping agent, ki bo po\u0161iljal RP-Discovery sporo\u010dila z navedbo, za katere skupine mora kateri RP biti poslu\u0161an. Na podlagi teh sporo\u010dil bodo obi\u010dajni PIM usmerjevalniki dolo\u010dili svoj RP. Mapping Agent je lahko kot sam RP usmerjevalnik, pa tudi kateri koli drug PIM usmerjevalnik. RP-Discovery se po\u0161ilja na naslov 224.0.1.40 s \u010dasovnikom enega minute.<br \/>\nPoglejmo proces podrobneje:<br \/>\nNastavimo R3 kot RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 kot mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nNa vseh drugih se bomo pripravljali na RP preko Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nKo enkrat nastavimo R3, bo za\u010del po\u0161iljati RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR2 bo po nastavitvi mapping agenta za\u010del pri\u010dakovati sporo\u010dila RP-Announce. Le ko najde vsaj en RP, bo za\u010del po\u0161iljati RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nTako, ko obi\u010dajni usmerjevalniki (PIM RP Listener) prejmejo ta sporo\u010dila, bodo vedeli, kje iskati RP.<br \/>\nEna glavnih te\u017eav Auto-RP je, da za prejemanje sporo\u010dil RP-Announce in RP-Discovery moramo po\u0161iljati PIM Join na naslove 224.0.1.39-40, a da bi to storili, moramo vedeti, kje se nahaja RP. Klasika problematike pi\u0161\u010danca in jajca. Za re\u0161itev te te\u017eave je bil izumljen na\u010din PIM Sparse-Dense-Mode. \u010ce usmerjevalnik ne pozna RP, deluje v na\u010dinu Dense-mode, \u010de ga pozna, pa v na\u010dinu Sparse-mode. Ko so na vmesnikih obi\u010dajnih usmerjevalnikov nastavljeni PIM Sparse-mode in ukaz ip pim autorp listener, bo usmerjevalnik deloval v na\u010dinu Dense-mode le za multicast Auto-RP protokola (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nTa funkcija deluje podobno kot Auto-RP. Vsak RP po\u0161ilja sporo\u010dilo mapping agentu, ki zbira informacije o mapiranju in nato pove ostalim usmerjevalnikom. Opisali bomo proces podobno kot pri Auto-RP:<br \/>\n1) Ko enkrat nastavimo R3 kot kandidata za RP z ukazom:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nBo R3 sprva miroval; da bi za\u010del po\u0161iljati posebna sporo\u010dila, mora najprej najti mapping agenta. Tako preidemo na drugi korak.<br \/>\n2) Nastavimo R2 kot mapping agenta:<\/p>\n<blockquote><p>ip pim bsr-kandidat loopback 0<\/p><\/blockquote>\n<p>\nR2 za\u010dne pos\u00edl\u00e1vat PIM Bootstrap zpr\u00e1vy, ve kter\u00fdch se uv\u00e1d\u00ed jako mapping agent:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nTato zpr\u00e1va je odesl\u00e1na na adresu 224.0.0.13, kterou protokol PIM pou\u017e\u00edv\u00e1 tak\u00e9 pro dal\u0161\u00ed sv\u00e9 zpr\u00e1vy. Tyto zpr\u00e1vy jsou odes\u00edl\u00e1ny ve v\u0161ech sm\u011brech a proto nen\u00ed probl\u00e9m s ku\u0159etem a vejcem, jak tomu bylo u Auto-RP.<br \/>\n3) Jakmile RP obdr\u017e\u00ed zpr\u00e1vu od BSR routeru, okam\u017eit\u011b ode\u0161le unicastovou zpr\u00e1vu na adresu BSR routeru:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPot\u00e9, co BSR obdr\u017e\u00ed informace o RP, roze\u0161le je multicastem na adresu 224.0.0.13, kterou sleduj\u00ed v\u0161echny PIM routery. Proto neexistuje ekvivalent p\u0159\u00edkazu <i>ip pim autorp listener<\/i> pro b\u011b\u017en\u00e9 routery v BSR.<br \/>\n<b>Anycast RP s protokolem Multicast Source Discovery (MSDP).<\/b><br \/>\nAuto-RP a BSR n\u00e1m umo\u017e\u0148uj\u00ed rozlo\u017eit z\u00e1t\u011b\u017e na RP n\u00e1sleduj\u00edc\u00edm zp\u016fsobem: Ka\u017ed\u00e1 multicastov\u00e1 skupina m\u00e1 pouze jedno aktivn\u00ed RP. Nen\u00ed mo\u017en\u00e9 rozlo\u017eit z\u00e1t\u011b\u017e pro jednu multicastovou skupinu mezi v\u00edce RP. MSDP to prov\u00e1d\u00ed pomoc\u00ed poskytov\u00e1n\u00ed RP router\u016fm se stejnou IP adresou s maskou 255.255.255.255. MSDP z\u00edsk\u00e1v\u00e1 informace pomoc\u00ed jedn\u00e9 z metod: statiky, Auto-RP nebo BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNa obr\u00e1zku m\u00e1me konfiguraci Auto-RP s MSDP. Oba RP jsou nastaveny se IP adresou 172.16.1.1\/32 na rozhran\u00ed Loopback 1 a pou\u017e\u00edvaj\u00ed se pro v\u0161echny skupiny. P\u0159i RP-Announce oba routery informuj\u00ed o sob\u011b, odkazuj\u00edce na tuto adresu. Auto-RP mapping agent, obdr\u017eev\u0161\u00ed informace, rozes\u00edl\u00e1 RP-Discovery o RP s adresou 172.16.1.1\/32. O s\u00edti 172.16.1.1\/32 informujeme routery pomoc\u00ed IGP a, odpov\u00eddaj\u00edc\u00edm zp\u016fsobem. T\u00edmto zp\u016fsobem PIM routery po\u017eaduj\u00ed nebo registruj\u00ed toky od RP, kter\u00fd je uveden jako next-hop v cest\u011b k s\u00edti 172.16.1.1\/32. Samotn\u00fd protokol MSDP je ur\u010den pro RP, aby si vym\u011b\u0148ovali zpr\u00e1vy o informac\u00edch o multicastu.<br \/>\nZva\u017eme takovou topologii:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Na\u010dela rada PIM protokola\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 vys\u00edl\u00e1 provoz na adresu 238.38.38.38 a zat\u00edm o n\u011bm v\u00ed pouze RP-R1. Switch7 a Switch8 po\u017e\u00e1dali o tuto skupinu. Routery R5 a R4 ode\u0161lou PIM Join na R1 a R3, odpov\u00eddaj\u00edc\u00edm zp\u016fsobem. Pro\u010d? Trasa do 13.13.13.13 u R5 bude odkazovat na R1 podle metriky IGP, stejn\u011b jako u R4.<br \/>\nRP-R1 v\u00ed o toku a za\u010dne jej vys\u00edlat sm\u011brem k R5, ale R4 o n\u011bm nic nev\u00ed, proto\u017ee R1 ho prost\u011b nebude takto odes\u00edlat. Proto je nutn\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>\nMezi sebou nav\u00e1\u017eou relaci a p\u0159i obdr\u017een\u00ed jak\u00e9hokoli toku budou informovat sv\u00e9ho sousedn\u00edho RP.<br \/>\nRP-R1, as soon as it receives a stream from Switch6, will immediately send a unicast MSDP Source-Active message containing information of type (S, G) \u2014 information about the source and destination of the multicast. Now, when RP-R3 knows that there is a source like Switch6, upon receiving a request from R4 for this stream, it will send a PIM Join towards Switch6, guided by the routing table. Consequently, R1, upon receiving such a PIM Join, will start sending traffic towards RP-R3.<br \/>\nMSDP operates over TCP, with RPs sending keepalive messages to each other to verify their liveliness. The timer is set to 60 seconds.<br \/>\nThe function of partitioning MSDP peers into different domains remains unclear, as the Keepalive and SA messages do not indicate affiliation with any domain. Additionally, in this topology, a configuration indicating different domains was tested \u2014 there was no difference in operation. <br \/>\nIf anyone can provide clarity, I would gladly read it in the comments.<br \/>\n<br \/>Izvor: <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.5 - 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\/sl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47Principles of the PIM Protocol | ProHoster","description":"The PIM protocol is a set of protocols for transmitting multicast in networks between routers. Neighbor relationships are established similarly to dynamic routing protocols.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}