{"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\/et\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>PIM-protokoll on protokollide kogum, mis edastab multikaasti v\u00f5rgus mar\u0161rutite vahel. Naabrussuhted luuakse samamoodi nagu d\u00fcnaamiliste marsruutimisprotokollide puhul. PIMv2 saadab iga 30 sekundi j\u00e4rel Hello s\u00f5numeid reserveeritud multikaadiga aadressile 224.0.0.13 (All-PIM-Routers). S\u00f5num sisaldab Hold Timers'i \u2014 tavaliselt 3.5 * Hello Timer, st vaikimisi 105 sekundit.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM kasutab kahte peamist t\u00f6\u00f6re\u017eiimi \u2014 Dense ja Sparse mode. Alustame Dense mode'ist. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Allika-p\u00f5hised jaotust koostised.<\/b><br \/>\nDense-mode'i re\u017eiimi on m\u00f5istlik kasutada juhul, kui on palju kliente erinevates multikaasti gruppides. Kui mar\u0161utitor saab multikaasti liiklust, kontrollib ta k\u00f5igepealt RPF reeglit. RPF \u2014 see reegel kontrollib multikaasti allikat unikaadis marsruutimiste tabeli kaudu. Liiklus peab tulema sellele liidesele, mille taga on antud host, vastavalt unikaadile marsruutimiste tabelile. See mehhanism lahendab probleemid, mis v\u00f5ivad tekkida multikaasti edastamisel.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 saab multikaasti s\u00f5numist teada allika (Source IP) ja kontrollib R1 ja R2 kahte voogu oma unikaadise marsruutimiste tabelis. Voog, mille liides on tabelis (R1 R3-le), edastatakse edasi, samas kui voog R2 hakatakse tagasi l\u00fckkama, kuna multikaasti allikani j\u00f5udmiseks tuleb pakette saata S0\/1-elt.<br \/>\nK\u00fcsimus on, mis juhtub, kui teil on kaks ekvivalentset marsruuti \u00fche ja sama metrikaga? Sellisel juhul valib mar\u0161utitor j\u00e4rgmise sammu nende marsruutide vahel. Sellel, kellel on k\u00f5rgem IP-aadress, see ka v\u00f5idab. Kui soovite seda k\u00e4itumist muuta, saate kasutada ECMP-d. T\u00e4iendavad andmed <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">siit<\/a><\/noindex>.<br \/>\nP\u00e4rast RPF reegli kontrollimist saadab mar\u0161utitor multikaastpaketi k\u00f5igile oma PIM naabritele, v\u00e4lja arvatud sellele, kellelt see pakett saadi. \u00dclej\u00e4\u00e4nud PIM mar\u0161utid kordavad seda protsessi. Tee, mille m\u00f6\u00f6da multikaastpakett l\u00e4ks allikast l\u00f5ppsaajateni, moodustab puu, mida nimetatakse \u2014 allika-p\u00f5hiseks jaotuspuuks, l\u00fchim tee puu (SPT), allika puu. Kolm erinevat nime, valige \u00fcksk\u00f5ik milline.<br \/>\nKuidas lahendada probleem, kui m\u00f5ned mar\u0161utid ei soovi mingit multikaasti voogu ja sellele ei ole kedagi edastada, kuid k\u00f5rgem mar\u0161utitor saadab seda? Selleks on v\u00e4lja m\u00f5eldud Prune mehhanism. <br \/>\n<b>Prune Message.<\/b><br \/>\nN\u00e4iteks R2 j\u00e4tkab R3-le multikaasti saatmist, kuigi R3 eemaldab selle RPF reegli t\u00f5ttu. Miks koormata kanalit? R3 saadab PIM Prune s\u00f5numi ja R2 eemaldab, saades selle s\u00f5numi, S0\/1 liidese (outgoing interface list) selle voogude jaoks, mille kaudu seda trafikut saata. <\/p>\n<blockquote><p>J\u00e4rgmine on PIM Prune s\u00f5numi formaalne m\u00e4\u00e4ratlus:<br \/>\nPIM Prune s\u00f5num saadetakse \u00fche ruuteri poolt teisele ruuterile, et sundida teist ruuterit eemaldama Prune'i saamise linki konkreetse (S,G) SPT-l.<\/p><\/blockquote>\n<p>\nP\u00e4rast Prune s\u00f5numi vastuv\u00f5tmist seab R2 Prune taimeri 3 minutiks. Kolme minuti p\u00e4rast hakkab see taas trafikut saatma, kuni ta ei saa uut Prune s\u00f5numit. See toimub PIMv1-s.<br \/>\nPIMv2-s on lisatud State Refresh taimer (vaikimisi 60 sekundit). Niipea kui R3-lt on saadetud Prune s\u00f5num, k\u00e4ivitatakse selle taimer R3-l. Taimeri m\u00f6\u00f6dumisel saadab R3 State Refresh s\u00f5numi, mis nullib R2-l 3-minutilise Prune taimeri selle grupi jaoks. <br \/>\nP\u00f5hjused Prune s\u00f5numi saatmiseks:<\/p>\n<ul>\n<li> Kui multikaasti pakett ei l\u00e4binud RPF kontrolli.<\/li>\n<li> Kui pole kohapeal \u00fchendatud kliente, kes on palunud multikaasti gruppi (IGMP Join) ja pole PIM naabreid, kellele v\u00f5iks multikaasti trafikut saata (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Graft s\u00f5num.<\/b><br \/>\nKujutame ette, et R3 ei soovinud R2-lt trafikut, saatis Prune'i ja sai multikaasti R1-lt. Kuid j\u00e4rsku kukkus R1-R3 vaheline kanal ja R3 j\u00e4i multikaastita. Saame oodata 3 minutit, kuni R2-l Prune taimer l\u00f5peb. 3 minutit on kaua oodata, et mitte oodata, on vajalik saata s\u00f5num, mis kohe eemaldab liidese S0\/1 R2-l pruned olekust. Selline s\u00f5num on Graft s\u00f5num. P\u00e4rast Graft s\u00f5numi vastuv\u00f5tmist saadab R2 vastuseks 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=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nVaadake seda skeemi. R1 edastab multicast'i kahe ruuteri segmendisse. R3 vastuvaidab ja edastab liiklust, R2 saab liiklust, kuid tal ei ole kedagi, kes edastaks. Ta saadab Prune s\u00f5numi R1-le antud segmendis. R1 peab eemaldama Fa0\/0 nimekirjast ja l\u00f5petama edastamise antud segmendis, kuid mis saab R3-st? R3 asub samas segmendis, sai samuti selle Prune s\u00f5numi ja m\u00f5istis olukorra t\u00f5sidust. Enne kui R1 l\u00f5petab edastamise, seadistab ta taimeri 3 sekundiks ja l\u00f5petab edastamise kolme sekundi p\u00e4rast. 3 sekundit \u2014 just nii palju aega on R3-l, et mitte kaotada oma multicast'i. Seet\u00f5ttu saadab R3 v\u00f5imalikult kiiresti Pim Join s\u00f5numi selle r\u00fchma jaoks ja R1 ei m\u00f5tle enam edastamise l\u00f5petamisele. Join s\u00f5numite kohta allpool.<br \/>\n<b>Assert s\u00f5num.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nKujutage ette olukorda: \u00fchte v\u00f5rku edastavad korraga kaks ruuterit. Nad saavad sama voolu allikast ja m\u00f5lemad edastavad seda \u00fchte v\u00f5rku e0 liidese kaudu. Seet\u00f5ttu peavad nad kindlaks tegema, kes on selle v\u00f5rgu ainus edastaja. Selleks kasutatakse Assert s\u00f5numeid. Kui R2 ja R3 tuvastavad multicast-traffiku dubleerimise, st R2-le ja R3-le j\u00f5uab multicast, mida nad ise edastavad, m\u00f5istavad ruuterid, et midagi on valesti. Ruuterid saadavad sellisel juhul Assert s\u00f5numeid, milles on kasutatud Administrative Distance ja marsruutimise meetrika, mille abil j\u00f5utakse multicast'i allikani \u2014 10.1.1.10. V\u00f5itja m\u00e4\u00e4ratakse j\u00e4rgmiselt:<\/p>\n<ol>\n<li>See, kellel on madalam AD.<\/li>\n<li>Kui AD-d on v\u00f5rdsed, siis see, kellel on madalam meetrika.<\/li>\n<li>Kui ka siin on v\u00f5rdsus, siis see, kellel on k\u00f5rgem IP v\u00f5rku, kuhu nad seda multicast'i edastavad.<\/li>\n<\/ol>\n<p>\nSelles h\u00e4\u00e4letuses v\u00f5itnud ruuterist saab Designated Router. DR valimiseks kasutatakse samuti Pim Hello. Artikli alguses n\u00e4idatud PIM Hello s\u00f5numis on DR v\u00e4li. V\u00f5idab see, kelle IP-aadress on sellel lingil k\u00f5rgem.<br \/>\nKasulik tabel:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE tabel.<\/b><br \/>\nP\u00e4rast PIM protokolli t\u00f6\u00f6 esialgset kaalumist peame aru saama, kuidas t\u00f6\u00f6tada multicast marsruutimise tabeliga. mroute tabelis hoitakse teavet selle kohta, milliseid vooge on kliendid taotlenud ja millised vood tulevad multicast serveritest. <br \/>\nN\u00e4iteks, kui m\u00f5nel liidesel saadakse IGMP Membership Report v\u00f5i PIM Join, lisatakse marsruutimistabelisse kirje t\u00fc\u00fcpi ( *, G ):<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSee m\u00e4rge t\u00e4hendab, et on saabunud p\u00e4ring liiklusele aadressilt 238.38.38.38. Lipp DC t\u00e4hendab, et multicasting t\u00f6\u00f6tab tihedas re\u017eiimis (Dense mode) ja C t\u00e4hendab, et saaja on otseselt \u00fchendatud ruuteriga, st ruuter sai IGMP liikmesuse raporti ning PIM Joini.<br \/>\nKui on olemas (S,G) t\u00fc\u00fcpi m\u00e4rge, t\u00e4hendab see, et meil on multicasting voog:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nV\u00e4ljal S \u2014 192.168.1.11, on meil m\u00e4\u00e4ratud multicasting allika IP-aadress, mida kontrollitakse RPF reegliga. Probleemide korral tuleks k\u00f5igepealt kontrollida unikaalset tabelit allika marsruudi osas. V\u00e4ljal Incoming Interface on n\u00e4idatud liides, kuhu multicasting saabub. Unikaalses marsruutimistabelis peab marsruut allikale viitama siin n\u00e4idatud liidesele. V\u00e4ljal Outgoing Interface on n\u00e4idatud, kuhu multicasting suunatakse. Kui see on t\u00fchi, t\u00e4hendab, et ruuterile ei ole selle liikluse osas saadetud p\u00e4ringuid. \u00dcksikasjalikku teavet k\u00f5ikide lippude kohta saab leida. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">siin<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nSparse-mode strateegia on vastupidine Dense-mode'ile. Kui Sparse-mode saab multicasting liiklust, saadab ta liiklust ainult nendele liidesele, kus on olnud p\u00e4ringud selle voogudega, n\u00e4iteks Pim Join v\u00f5i IGMP Report s\u00f5numid, mis esitavad selle liikluse p\u00e4ringu.<br \/>\nSM ja DM sarnased elemendid:<\/p>\n<ul>\n<li> Naabrite suhted moodustatakse samuti nagu PIM DM-is.<\/li>\n<li> Kehtib RPF reegel.<\/li>\n<li> DR valik on sarnane.<\/li>\n<li> Prune Overrides mehhanism ja Assert s\u00f5numid on sarnased.<\/li>\n<\/ul>\n<p>\nSelleks, et kontrollida, kellele, kus ja millist multicasting liiklust on v\u00f5rgu tarvis, on vajalik \u00fchine infokeskus. Selliseks keskuseks on Rendezvous Point (RP). K\u00f5ik, kes soovivad mingit multicasting liiklust v\u00f5i kes hakkavad saama multicasting liiklust allikast, saadavad selle RP-le.<br \/>\nKui RP saab multicasting liiklust, saadab ta selle ruuteritele, kes on enne seda liiklust k\u00fcsinud. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nKujutame ette topoloogiat, kus RP on R3. Kui R1 saab liiklust S1-lt, kapseldab ta selle multicasting paketi unikaalses PIM Register s\u00f5numis ja saadab selle RP-le. Kuidas ta teab, kes on RP? Antud juhul on see staatiliselt seadistatud, kuid d\u00fcnaamilise RP seadistamise teemal r\u00e4\u00e4gime hiljem. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP vaatab \u2014 kas oli teavet kelleltki, kes soovis seda liiklust saada? Oletame, et ei olnud. Siis saadab RP R1-le teate PIM Register-Stop, mis t\u00e4hendab \u2014 keegi ei vaja seda multicast'i, registreerimine on tagasi l\u00fckatud. R1 ei saadeta multicast'i. Kuid multicast'i allikas saadab selle siiski, nii et R1, p\u00e4rast Register-Stop'i saamist, k\u00e4ivitab Register-Suppression timer, mille pikkus on 60 sekundit. 5 sekundit enne selle taimeri aegumist, saadab R1 t\u00fchja Register teate Null-Register bit'iga (st ilma kapseldatud multicast paketi) RP suunas. RP k\u00e4itub j\u00e4rgmiselt:<\/p>\n<ul>\n<li> Kui saajaid ei olnud, siis ta vastab Register-Stop teatega.<\/li>\n<li> Kui saajad ilmuvad, siis ta ei vasta sellele. R1, saamata oma registreerimisele 5 sekundi jooksul tagasi l\u00fckkamist, r\u00f5\u00f5mustab ja saadab Register teate kapseldatud multicast'iga RP suunas.<\/li>\n<\/ul>\n<p>\nKuidas multicast j\u00f5uab RP-ni, paistab olevat selge, n\u00fc\u00fcd proovime vastata k\u00fcsimusele, kuidas RP toimetab liikluse saajateni. Siin on vaja tutvustada uut m\u00f5istet \u2014 root-path tree (RPT). RPT on puud, mille juur on RP, kasvab saajate suunas, hargnedes igal PIM-SM ruuteril. RP loob selle, saades PIM Join teateid ja lisab puusse uue oksa. Ja nii teeb iga alamruuter. \u00dcldine reegel n\u00e4eb v\u00e4lja j\u00e4rgmiselt:<\/p>\n<ul>\n<li> Kui PIM-SM ruuter saab PIM Join teate m\u00f5nel liidesel, v\u00e4lja arvatud liides, mille taha RP varjunud on, siis ta lisab puusse uue oksa.<\/li>\n<li> Oks lisatakse ka siis, kui PIM-SM ruuter saab IGMP Membership Report'it otse \u00fchendatud hostilt. <\/li>\n<\/ul>\n<p>\nKujutame ette, et meil on multicast klient ruuteri R5 juures grupis 228.8.8.8. Kui R5 saab IGMP Membership Report'i hostilt, saadab R5 PIM Join'i RP suunas ja lisab puusse liidese, mis vaatab hosti poole. Edasi, R4 saab R5-lt PIM Join'i, lisab puusse liidese Gi0\/1 ja saadab PIM Join'i RP suunas. L\u00f5puks saab RP (R3) PIM Join'i ja lisab Gi0\/0 puusse. Nii toimub multicast saaja registreerimine. Meil tekib puu juurega R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nP\u00e4rast seda saadetakse R1-le PIM Join ja R1 hakkab saatma multikaust liiklust. Oluline on m\u00e4rkida, et kui host k\u00fcsib liiklust enne kui multikaust hakkab edastama, siis RP ei saada PIM Join'i ega edasta midagi R1 suunas.<br \/>\nKui \u00e4kki multikaustatoimetamise ajal ei soovi host seda enam vastu v\u00f5tta, siis niipea kui RP saab PIM Prune s\u00f5numi liideselt Gi0\/0, saadab ta kohe PIM Register-Stop'i R1-le ja seej\u00e4rel PIM Prune s\u00f5numi liideselt Gi0\/1. PIM Register-Stop saadetakse unicastiga sellele aadressile, kust tuli PIM Register.<br \/>\nNagu me varem r\u00e4\u00e4kisime, niipea kui ruuter saadab PIM Join teisele, n\u00e4iteks R5-le R4-l, lisatakse R4-le kirje:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nJa k\u00e4ivitub taimer, mille jooksul R5 peab pidevalt saatma PIM Join s\u00f5numeid, vastasel korral R4 eemaldab selle v\u00e4ljuvate nimekirjast. R5 saadab iga 60 sekundi tagant PIM Join s\u00f5numeid.<br \/>\n<b>L\u00fchima tee puu vahetus.<\/b><br \/>\nLisame liidese R1 ja R5 vahele ning vaatame, kuidas liiklus sellises topoloogias voolab. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nOletame, et liiklus liikus ja saadi vana skeemi R1-R2-R3-R4-R5 kaudu ja n\u00fc\u00fcd oleme lisanud ja seadistanud liidese R1 ja R5 vahel.<br \/>\nEsimene samm on see, et unicast marsruudi tabel R5-s rekonstrueeritakse ja n\u00fc\u00fcd on v\u00f5rk 192.168.1.0\/24 saavutatav R5 liidese Gi0\/2 kaudu. N\u00fc\u00fcd, kui R5 saab multikaust liiklust liideselt Gi0\/1, m\u00f5istab ta, et RPF reegel ei rahuldata ja multikaust oleks m\u00f5istlikum saada Gi0\/2 kaudu. Ta peab RPT-st lahti \u00fctlema ja ehitama l\u00fchema puu, mida nimetatakse l\u00fchima tee puuks (SPT). Selleks saadab ta Gi0\/2 kaudu PIM Join R1-le ja R1 hakkab saatma multikaust ka Gi0\/2 kaudu. N\u00fc\u00fcd peab R5 RPT-st lahti \u00fctlema, et mitte saada kahte koopiat. Selleks saadab ta Prune s\u00f5numi, m\u00e4rkides allika IP-aadressi ja lisades spetsiaalse biti \u2014 RPT-bit. See t\u00e4hendab, et \u00e4rge saatke mulle liiklust, mul on parem puu. RP saadab samuti R1 suunas PIM Prune s\u00f5numeid, kuid ei saada Register-Stop s\u00f5numit. Veel \u00fcks omadus: R5 hakkab pidevalt saatma PIM Prune RP-le, kuna R1 j\u00e4tkab PIM Register'i saatmist RP-le iga minuti tagant. RP vastab tema taotlustele keeldumisega, kuni uusi huvilisi ei ole. R5 teavitab RP-d, et ta j\u00e4tkab multikaust liikluse saamist l\u00e4bi SPT.<br \/>\n<b>D\u00fcnaamiline RP otsing. <br \/>\nAuto-RP.<\/b><br \/>\nSee tehnoloogia on Cisco'i poolt omandatud ja ei ole eriti populaarne, kuid siiski on eluj\u00f5uline. Auto-RP t\u00f6\u00f6 koosneb kahest p\u00f5hietapist:<br \/>\n1) RP saadab RP-Announce s\u00f5numeid reserveeritud aadressile \u2014 224.0.1.39, kuulutades end RP-ks kas k\u00f5igi v\u00f5i teatud gruppide jaoks. S\u00f5num saadetakse iga minuti tagant.<br \/>\n2) On vajalik RP mapping agent, mis saadab RP-Discovery s\u00f5numeid, m\u00e4rkides, milliste gruppide jaoks milline RP kuulata tuleb. Just sellest s\u00f5numist m\u00e4\u00e4rab tavap\u00e4rased PIM ruuteriid endale RP. Mapping Agent v\u00f5ib olla kas RP ruuter ise v\u00f5i m\u00f5ni eraldi PIM ruuter. RP-Discovery saadetakse aadressile 224.0.1.40 \u00fches minutis.<br \/>\nVaadakem protsessi l\u00e4hemalt:<br \/>\nSeadistame R3 RP-ks:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 kui mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nJa k\u00f5ikidel teistel ootame RP-d Auto-RP kaudu:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nNiipea kui me R3 seadistame, hakkab ta saatma RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nJa R2, p\u00e4rast mapping agent-iks seadistamist, hakkab ootama RP-Announce s\u00f5numeid. Alles siis, kui ta leiab v\u00e4hemalt \u00fche RP, hakkab ta saatma RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNii saavad tavalised ruuterid (PIM RP Listener) teada, kust RP-d otsida, kui nad saavad selle s\u00f5numi.<br \/>\n\u00dcks peamisi Auto-RP probleeme on see, et RP-Announce ja RP-Discovery s\u00f5numite saamiseks tuleb saata PIM Join aadressidele 224.0.1.39-40, aga selleks, et saata, peab teadma, kus RP asub. Klassikaline kana ja muna probleem. Selle probleemi lahendamiseks t\u00f6\u00f6tati v\u00e4lja PIM Sparse-Dense-Mode re\u017eiim. Kui ruuter ei tea RP-d, t\u00f6\u00f6tab ta Dense-mode re\u017eiimis, ja kui teab, siis Sparse-mode re\u017eiimis. Kui tavaruuterite liidetes on seadistatud PIM Sparse-mode ja k\u00e4sk ip pim autorp listener, hakkab ruuter Dense-mode t\u00f6\u00f6le ainult Auto-RP protokolli multicast jaoks (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nSee funktsioon t\u00f6\u00f6tab sarnaselt Auto-RP-le. Iga RP saadab s\u00f5numi mapping agent-le, kes kogub mappimise teavet ja r\u00e4\u00e4gib edasi k\u00f5ikidele teistele ruuteritele. Kirjeldame protsessi sarnaselt Auto-RP-le:<br \/>\n1) Kui oleme seadistanud R3 RP kandidaadina, k\u00e4suga:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nSiis ei tee R3 midagi, et alustada spetsiaalsete s\u00f5numite saatmist, peab ta k\u00f5igepealt leidma mapping agent-i. Nii et liigume teise sammu juurde.<br \/>\n2) Seadistame R2 mapping agent-iks:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 hakkab saatma PIM Bootstrap s\u00f5numeid, kus m\u00e4\u00e4ratleb end kaardistamisagendina:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSee s\u00f5num saadetakse aadressile 224.0.0.13, mida PIM protokoll kasutab ka teiste oma s\u00f5numite jaoks. See saadab neid igas suunas ja seega ei ole kana ja muna probleemi, nagu Auto-RP puhul.<br \/>\n3) Niipea kui RP saab s\u00f5numi BSR ruuterilt, saadab ta kohe unikaalse s\u00f5numi BSR ruuteri aadressile:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nP\u00e4rast seda, kui BSR on saanud teavet RP kohta, saadab ta selle m\u00e4ngehngua multicastina aadressile 224.0.0.13, mida kuulavad k\u00f5ik PIM ruuterid. Seega, BSR-is pole korraldust <i>ip pim autorp listener<\/i> tavalisetele ruuteritele.<br \/>\n<b>Anycast RP koos Multicast Source Discovery Protocol (MSDP) abil.<\/b><br \/>\nAuto-RP ja BSR v\u00f5imaldavad meil jaotada koormust RP-dele j\u00e4rgmiselt: Igal multicast grupil on ainult \u00fcks aktiivne RP. \u00dche multicast grupi jaoks ei saa koormust jaotada mitme RP vahel. MSDP teeb seda, andes RP ruuteritele sama ip-aadressi maskiga 255.255.255.255. MSDP saab teavet \u00fchtede meetodite kaudu: staatika, Auto-RP v\u00f5i BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nPildil on meil Auto-RP konfiguratsioon koos MSDP-ga. M\u00f5lemad RP-d on seadistatud ip-aadressiga 172.16.1.1\/32 Loopback 1 liidesele ja seda kasutatakse k\u00f5igi gruppide jaoks. RP-Announce k\u00e4igus r\u00e4\u00e4givad m\u00f5lemad ruuterid endast, viidates sellele aadressile. Auto-RP kaardistamisagent, saades teavet, levitab RP-Discovery RP-st aadressiga 172.16.1.1\/32. Ruuteritele r\u00e4\u00e4gime 172.16.1.1\/32 v\u00f5rgu kohta IGP kaudu. Seega, PIM ruuterid k\u00fcsivad v\u00f5i registreerivad vooge, mille RP on m\u00e4\u00e4ratud kui j\u00e4rgmine samm 172.16.1.1\/32 v\u00f5rgu Marsruudil. MSDP protokoll on m\u00f5eldud RP-dele, et jagada teavet multicastide kohta.<br \/>\nVaatame sellist topoloogiat:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 levitab liiklust aadressil 238.38.38.38 ja selle kohta teab seni vaid RP-R1. N\u00fc\u00fcd Switch7 ja Switch8 on selle grupi kohta taotluse esitanud. Ruuterid R5 ja R4 saadavad PIM Join R1 ja R3, vastavalt. Miks? Marsruut aadressini 13.13.13.13 R5-l viitab R1-le IGP meetriga, nagu ka R4-l.<br \/>\nRP-R1 teab voogust ja hakkab seda R5 suunas levitama, kuid R4 ei tea sellest midagi, kuna R1 ei saada seda lihtsalt. Seega on MSDP vajalik. Seame selle \u00fcles R1-l ja R5-l:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 R1-l<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 R3-l<\/p><\/blockquote>\n<p>\nNeed loovad omavahel seansi ja s\u00f5numi saamisel edastavad nad teavet oma RP naabrile.<br \/>\nRP-R1, kui see saab voolu Switch6-lt, saadab kohe unicastiga MSDP Source-Active s\u00f5numi, kus on teave t\u00fc\u00fcp (S, G) \u2014 teave allika ja multicast sihtkoha kohta. N\u00fc\u00fcd, kui RP-R3 teab, et selline allikas nagu Switch6 eksisteerib, saadab ta, saades p\u00e4ringu R4-lt selle voolu kohta, Switch6 suunas PIM Join, tuginedes marsruutimistabelile. Seet\u00f5ttu, kui R1 saab sellise PIM Join s\u00f5numi, hakkab see suunama liiklust RP-R3 poole.<br \/>\nMSDP t\u00f6\u00f6tab TCP p\u00f5hjal, RP saadavad \u00fcksteisele keepalive s\u00f5numeid eluj\u00f5ulisuse kontrollimiseks. Ajastusts\u00fckkel on 60 sekundit.<br \/>\nMSDP peeride jagamise funktsioon erinevatesse domeenidesse j\u00e4\u00e4b ebaselgeks, kuna Keepalive ja SA s\u00f5numites ei n\u00e4idata kuulumist \u00fchtegi domeeni. Samuti testiti antud topoloogias konfigureerimist erinevate domeenide m\u00e4\u00e4ramisega \u2014 t\u00f6\u00f6protsessis ei olnud erinevusi. <br \/>\nKui keegi suudab selgust tuua, loen hea meelega kommentaarides.<br \/>\n<br \/>Allikas: <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\/et\/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=\"et_EE\" \/>\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\/et\/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\udd47PIM-protokolli t\u00f6\u00f6p\u00f5him\u00f5tted | ProHoster","description":"PIM-protokoll on protokollide kogum multicast'i edastamiseks v\u00f5rkudes ruuterite vahel. Naabrussuhted luuakse sarnaselt d\u00fcnaamiliste marsruutimisprotokollide korral.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}