{"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\/hr\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Na\u010dela rada PIM protokola","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>PIM protokol je skup protokola za prijenos multicast-a u mre\u017eama izme\u0111u usmjeriva\u010da. Odnosi susjedstva se uspostavljaju na sli\u010dan na\u010din kao i u slu\u010daju dinami\u010dkih protokola usmjeravanja. PIMv2 \u0161alje svakih 30 sekundi Hello poruke na rezerviranu multicast adresu 224.0.0.13 (All-PIM-Routers). Poruka sadr\u017ei Hold Timers \u2014 obi\u010dno jednako 3.5*Hello Timer, \u0161to je 105 sekundi prema zadanim postavkama.<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 na\u010dina rada \u2014 Dense i Sparse mode. Po\u010dnimo s Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Stabla na temelju izvora.<\/b><br \/>\nDense-mode je korisno koristiti kada ima mnogo klijenata razli\u010ditih multicast grupa. Kada usmjeriva\u010d primi multicast promet, prvo provjerava pravilo RPF. RPF \u2014 to pravilo koristi se za provjeru izvora multicast-a s unicast tablicom usmjeravanja. Potrebno je da promet dolazi na onaj su\u010delje, iza kojeg se nalaze navedeni host prema unicast tablici usmjeravanja. Ovaj mehanizam rje\u0161ava problem nastanka petlje tijekom prijenosa 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 provjerava dva toka od R1 i R2 prema svojoj unicast tablici. Tok s tog su\u010delja na koje ukazuje tablica (R1 prema R3) bit \u0107e proslije\u0111en dalje, dok \u0107e tok od R2 biti odbijen, jer da bi do\u0161ao do izvora multicast-a, potrebno je slati pakete putem S0\/1.<br \/>\nPitanje je \u0161to \u0107e se dogoditi ako imate dva ekvivalentna puta s istom metri\u010dkom vrijedno\u0161\u0107u? U tom slu\u010daju, usmjeriva\u010d \u0107e birati prema next-hop ovih puteva. Tko ima vi\u0161u ip adresu, taj pobje\u0111uje. Ako je potrebno promijeniti 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\">ovdje<\/a><\/noindex>.<br \/>\nNakon provjere pravila RPF, usmjeriva\u010d \u0161alje multicast paket svim svojim PIM susjedima, osim onome od kojeg je primio ovaj paket. Ostali PIM usmjeriva\u010di ponavljaju ovaj proces. Put koji je multicast paket pro\u0161ao od izvora do krajnjih primatelja oblikuje stablo koje se naziva \u2014 source-based distribution tree, shortest-path tree (SPT), source tree. Tri razli\u010dita naziva, birajte bilo koji.<br \/>\nKako rije\u0161iti problem kada nekim usmjeriva\u010dima nije potreban neki multicast tok i ne mogu ga proslijediti, a vi\u0161i usmjeriva\u010d ga \u0161alje? Za to je zami\u0161ljen Prune mehanizam. <br \/>\n<b>Prune poruka.<\/b><br \/>\nNa primjer, R2 \u0107e nastaviti slati R3 multicast, iako R3 prema RPF pravilu odbacuje to. Za\u0161to optere\u0107ivati kanal? R3 \u0161alje PIM Prune poruku, a R2 \u0107e, prilikom primanja ove poruke, ukloniti su\u010delje S0\/1 iz popisa (outgoing interface list) za taj tok, popis su\u010delja s kojih treba slati taj promet. <\/p>\n<blockquote><p>Sljede\u0107a je formalnija definicija PIM Prune poruke:<br \/>\nPIM Prune poruka se \u0161alje od jednog usmjeriva\u010da drugom usmjeriva\u010du kako bi se drugom usmjeriva\u010du nalo\u017eilo da ukloni vezu na kojoj je primljena Prune poruka iz odre\u0111enog (S,G) SPT.<\/p><\/blockquote>\n<p>\nNakon primanja Prune poruke, R2 postavlja Prune tajmer na 3 minute. Nakon tri minute ponovno \u0107e po\u010deti slati promet, sve dok ne primi novu Prune poruku. Ovo je u PIMv1.<br \/>\nU PIMv2 dodan je State Refresh tajmer (prema zadanim postavkama 60 sekundi). \u010cim se po\u0161alje Prune poruka s R3, ovaj tajmer se pokre\u0107e na R3. Nakon isteka ovog tajmera, R3 \u0107e poslati State Refresh poruku koja \u0107e resetirati trominutni Prune tajmer na R2 za tu grupu. <br \/>\nRazlozi za slanje Prune poruke:<\/p>\n<ul>\n<li> Kada multicast paket ne pro\u0111e RPF provjeru.<\/li>\n<li> Kada nema lokalno povezanih klijenata koji su zatra\u017eili multicast grupu (IGMP Join) i nema PIM susjeda kojima se mo\u017ee slati multicast promet (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Graft Poruka.<\/b><br \/>\nZamislite da R3 nije \u017eelio promet od R2, poslao je Prune i primao multicast od R1. No, odjednom, veza izme\u0111u R1 i R3 je pala i R3 je ostao bez multikasta. Mo\u017eete \u010dekati 3 minute dok ne istekne Prune tajmer na R2. 3 minute \u010dekanja je dugo, kako ne biste \u010dekali, potrebno je poslati poruku koja \u0107e odmah izvesti ovo su\u010delje S0\/1 na R2 iz pruned stanja. Takva poruka \u0107e biti Graft poruka. Nakon primanja Graft poruke, R2 \u0107e poslati Graft-ACK kao odgovor.<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 \/>\nPogledajmo ovaj dijagram. R1 emitira multicast u segment s dva usmjeriva\u010da. R3 prima i emitira promet, dok R2 prima, ali nije koga da emitira promet. R2 \u0161alje Prune poruku R1 u taj segment. R1 mora ukloniti Fa0\/0 iz popisa i prestati emitirati u taj segment, ali \u0161to je s R3? R3 se tako\u0111er nalazi u istom segmentu, tako\u0111er je primio ovu Prune poruku i shvatio je svu tragediju situacije. Prije nego \u0161to R1 prestane emitirati, postavlja tajmer na 3 sekunde i prestat \u0107e emitirati nakon 3 sekunde. 3 sekunde \u2014 to je vrijeme koje R3 ima da ne izgubi svoj multicast. Stoga R3 \u0161to je br\u017ee mogu\u0107e \u0161alje Pim Join poruku za ovu grupu i R1 vi\u0161e ne razmi\u0161lja o prestanku emitiranja. O Join porukama vi\u0161e u nastavku.<br \/>\n<b>Assert poruka.<\/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 \/>\nZamislimo sljede\u0107u situaciju: u jednu mre\u017eu emitiraju dva usmjeriva\u010da. Primaju isti tok od izvora, i oboje ga emitiraju u jednu mre\u017eu iza su\u010delja e0. Stoga moraju odrediti tko \u0107e biti jedini emitator za ovu mre\u017eu. Za to se koriste Assert poruke. Kada R2 i R3 otkriju dupliciranje multicast prometa, to jest, kada na R2 i R3 stigne multicast koji oni sami emitiraju, usmjeriva\u010di shva\u0107aju da ne\u0161to nije u redu. U tom slu\u010daju, usmjeriva\u010di \u0161alju Assert poruke koje uklju\u010duju Administrativnu udaljenost i metriku rute pomo\u0107u koje se dolazi do izvora multicast-a \u2014 10.1.1.10. Pobjednik se odre\u0111uje na sljede\u0107i na\u010din:<\/p>\n<ol>\n<li>Onaj s ni\u017eom AD.<\/li>\n<li>Ako su AD isti, tada onaj s ni\u017eom metrikom.<\/li>\n<li>Ako je i ovdje jednako, pobjednik je onaj s vi\u0161im IP-om u mre\u017ei u koju emitiraju ovaj multicast.<\/li>\n<\/ol>\n<p>\nPobjednik u ovoj glasovnoj akciji postaje Designated Router. Za odabir DR-a tako\u0111er se koriste Pim Hello. Na po\u010detku \u010dlanka pokazana je PIM Hello poruka, gdje se mo\u017ee primijetiti DR polje. Pobjednik je onaj s vi\u0161im IP adresama na ovoj vezi.<br \/>\nKorisna tablica:<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 Tablica.<\/b><br \/>\nNakon prvotnog pregleda rada PIM protokola, potrebno je shvatiti kako raditi s multicast tablicom usmjeravanja. U mroute tablici pohranjuje se informacija o tome koji su tokovi zatra\u017eeni od strane klijenata i koji tokovi dolaze s multicast poslu\u017eitelja. <br \/>\nNa primjer, prilikom primanja IGMP Membership Report ili PIM Join na nekom su\u010delju, u tablicu usmjeravanja dodaje se 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 \/>\nOva je evidencija koja ozna\u010dava da je primljen zahtjev za promet s adresom 238.38.38.38. Zastavica DC ozna\u010dava da \u0107e multicast raditi u re\u017eimu Dense mode, a C ozna\u010dava da je primatelj izravno povezan s usmjeriva\u010dem, tj. usmjeriva\u010d je primio IGMP Membership Report i PIM Join.<br \/>\nAko postoji zapis tipa (S,G) to zna\u010di da imamo multicast protok:<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 \/>\nU polju S - 192.168.1.11, naveli smo IP adresu izvora multicast-a, koja \u0107e biti provjeravana prema RPF pravilu. U slu\u010daju problema, prvo treba provjeriti unicast tablicu za putanju do izvora. U polju Incoming Interface navodi se su\u010delje na koje dolazi multicast. U unicast tablici usmjeravanja, putanja do izvora treba pokazivati na su\u010delje navedeno ovdje. U Outgoing Interface ozna\u010deno je prema gdje \u0107e multicast biti preusmjeren. Ako je prazno, to zna\u010di da nije bilo zahtjeva za taj promet prema usmjeriva\u010du. Detaljnije informacije o svim zastavicama mogu se na\u0107i. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">ovdje<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nStrategija Sparse-mode je suprotna Dense-mode. Kada Sparse-mode primi multicast promet, \u0161alje promet samo preko onih su\u010delja na kojima su bili zahtjevi za tim protokom, poput Pim Join ili IGMP Report poruka koje tra\u017ee taj promet.<br \/>\nSli\u010dni elementi za SM i DM:<\/p>\n<ul>\n<li> Odnosi susjedstva se grade na isti na\u010din kao u PIM DM.<\/li>\n<li> Primjenjuje se RPF pravilo.<\/li>\n<li> Odabir DR je sli\u010dan.<\/li>\n<li> Mehanizam Prune Overrides i poruke Assert su sli\u010dne.<\/li>\n<\/ul>\n<p>\nZa kontrolu toga kome, gdje i koji multicast promet je potreban u mre\u017ei, potreban je zajedni\u010dki informacijski centar. Takav centar \u0107e biti Rendezvous Point (RP). Svi koji \u017eele neki multicast promet ili su po\u010deli primati multicast promet od izvora, \u0161alju ga na RP.<br \/>\nKada RP primi multicast promet, poslat \u0107e ga onim usmjeriva\u010dima koji su ranije zatra\u017eili taj 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 \/>\nZamislimo takvu topologiju, gdje je RP R3. \u010cim R1 primi promet od S1, inkapsulira ovaj multicast paket u unicast PIM Register poruku i \u0161alje je na RP. Kako on zna tko je RP? U ovom slu\u010daju, postavljen je stati\u010dki, a o dinami\u010dkom postavljanju RP razgovarat \u0107emo kasnije. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP \u0107e pregledati je li bilo informacija od nekoga tko bi \u017eelio primati ovaj promet? Pretpostavimo da nije bilo. Tada \u0107e RP poslati R1 poruku PIM Register-Stop, \u0161to zna\u010di da nikome nije potreban ovaj multicast i registracija je odbijena. R1 ne\u0107e slati multicast. No, izvor hosta multicast-a \u0107e ga slati, tako da \u0107e R1, nakon primanja Register-Stop, pokrenuti tajmer Register-Suppression timer, koji traje 60 sekundi. Pet sekundi prije isteka ovog tajmera, R1 \u0107e poslati praznu Register poruku s Null-Register bit (zna\u010di bez inkapsuliranog multicast paketa) prema RP-u. RP \u0107e sa svoje strane djelovati na slijede\u0107i na\u010din:<\/p>\n<ul>\n<li> Ako nije bilo primatelja, tako da ih ni nema, on \u0107e odgovoriti porukom Register-Stop.<\/li>\n<li> Ako su se primatelji pojavili, ne\u0107e mu na nikakav na\u010din odgovoriti. R1, ne primiv\u0161i odbijenicu na svoju registraciju u roku od 5 sekundi, obradovat \u0107e se i poslati Register poruku s inkapsuliranim multicastom prema RP-u.<\/li>\n<\/ul>\n<p>\nSada kada smo shvatili kako multicast dolazi do RP-a, poku\u0161ajmo odgovoriti na pitanje kako RP dostavlja promet do primatelja. Ovdje je potrebno uvesti novi pojam \u2014 root-path tree (RPT). RPT je stablo s korijenom u RP-u, koje raste prema primateljima, razgranavaju\u0107i se na svakom PIM-SM usmjeriva\u010du. RP ga stvara primaju\u0107i PIM Join poruke i dodaje novu granu u stablo. I tako svaki ni\u017ei usmjeriva\u010d \u010dini. Op\u0107e pravilo glasi:<\/p>\n<ul>\n<li> Kada PIM-SM usmjeriva\u010d primi PIM Join poruku na nekom su\u010delju, osim su\u010delja iza kojeg se skriva RP, dodaje novu granu u stablo.<\/li>\n<li> Tako\u0111er, grana se dodaje kada PIM-SM usmjeriva\u010d primi IGMP Membership Report s neposredno povezane hosta. <\/li>\n<\/ul>\n<p>\nPretpostavimo da imamo multicast klijenta na usmjeriva\u010du R5 na grupi 228.8.8.8. \u010cim R5 primi IGMP Membership Report od hosta, R5 \u0161alje PIM Join prema RP-u, a sam dodaje su\u010delje koje gleda na host u stablo. Nadalje, R4 prima PIM Join od R5, dodaje su\u010delje Gi0\/1 u stablo i \u0161alje PIM Join prema RP-u. Na kraju, RP (R3) prima PIM Join i dodaje Gi0\/0 u stablo. Tako se doga\u0111a registracija primatelja multicast-a. Stablo se gradi s korijenom R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nNakon toga \u0107e biti poslan PIM Join R1, a R1 \u0107e po\u010deti slati multicast promet. Va\u017eno je napomenuti da ako host zatra\u017ei promet prije nego \u0161to je multicast emitiranje zapo\u010delo, RP ne\u0107e poslati PIM Join i uop\u0107e ni\u0161ta ne\u0107e slati prema R1.<br \/>\nAko tijekom slanja multimedijalnog sadr\u017eaja host odlu\u010di prekinuti primanje, \u010dim RP primi PIM Prune na su\u010delju Gi0\/0, odmah \u0107e poslati PIM Register-Stop izravno na R1, a zatim i PIM Prune poruku preko su\u010delja Gi0\/1. PIM Register-Stop se \u0161alje unicastom na adresu s koje je primljen PIM Register.<br \/>\nKao \u0161to smo ranije spomenuli, \u010dim usmjeriva\u010d po\u0161alje PIM Join drugom, primjerice R5 na R4, na R4 se dodaje zapis:<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 \/>\nI pokre\u0107e se tajmer, koji mora stalno slati PIM Join poruke kako bi se tajmer resetirao, ina\u010de \u0107e R4 isklju\u010diti iz outgoing liste. R5 \u0107e slati PIM Join poruke svakih 60 sekundi.<br \/>\n<b>Prebacivanje najkra\u0107eg putanjskog stabla.<\/b><br \/>\nDodati \u0107emo su\u010delje izme\u0111u R1 i R5, vidjet \u0107emo kako \u0107e promet te\u0107i u ovoj 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 \/>\nPretpostavimo da je promet slao i priman prema staroj shemi R1-R2-R3-R4-R5 i sada smo povezali i postavili su\u010delje izme\u0111u R1 i R5.<br \/>\nPrvo, unicast tablica usmjeravanja na R5 \u0107e se prestrukturirati i sada se mre\u017ea 192.168.1.0\/24 mo\u017ee dose\u0107i putem su\u010delja R5 Gi0\/2. Sada, kada R5 prima multicast kroz su\u010delje Gi0\/1, shva\u0107a da pravilo RPF nije zadovoljeno i logi\u010dnije je primati multicast na Gi0\/2. Mora se isklju\u010diti iz RPT-a i izgraditi kra\u0107e stablo, koje se naziva Najkra\u0107e putanjsko stablo (SPT). Za to, kroz Gi0\/2 \u0161alje PIM Join na R1, a R1 po\u010dinje slati multicast i preko Gi0\/2. Sada se R5 mora odjaviti iz RPT-a da ne bi primao dva primjerka. Za to \u0161alje Prune poruku navode\u0107i IP adresu izvora i ubacuju\u0107i posebnu bit \u2014 RPT-bit. To zna\u010di da ne trebam slati promet, ovdje imam bolje stablo. RP tako\u0111er \u0161alje PIM Prune poruke prema R1, ali ne \u0161alje Register-Stop poruku. Jo\u0161 jedna posebnost: R5 \u0107e stalno slati PIM Prune na RP, jer R1 svakih minuta nastavlja slati PIM Register na RP. Dok ne bude novih zainteresiranih za taj promet, RP \u0107e mu odbijati zahtjev. R5 obavje\u0161tava RP da nastavlja primati multicast preko SPT-a.<br \/>\n<b>Dinami\u010dko tra\u017eenje RP. <br \/>\nAuto-RP.<\/b><br \/>\nOva tehnologija je vlasni\u010dka od Cisco-a i ne u\u017eiva posebnu popularnost, ali i dalje je prisutna. Rad Auto-RP se sastoji od dva osnovna koraka:<br \/>\n1) RP \u0161alje RP-Announce poruke na rezerviranu adresu \u2014 224.0.1.39, objavljuju\u0107i se kao RP ili za sve ili za odre\u0111ene grupe. Ova poruka se \u0161alje svake minute.<br \/>\n2) Potreban je RP mapping agent koji \u0107e slati RP-Discovery poruke sa naglaskom na to koje grupe treba da slu\u0161aju koji RP. Upravo iz ove poruke, obi\u010dni PIM ruteri \u0107e odrediti svoj RP. Mapping agent mo\u017ee biti ili sam RP ruter, ili neki drugi PIM ruter. RP-Discovery se \u0161alje na adresu 224.0.1.40 sa tajmerom od jedne minute.<br \/>\nPogledajmo proces detaljnije:<br \/>\nPostavi\u0107emo R3 kao RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 kao mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nA na svim ostalim o\u010dekujemo RP preko Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\n\u010cim postavimo R3, on \u0107e po\u010deti slati 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 \/>\nA R2, nakon pode\u0161avanja kao mapping agent, \u0107e po\u010deti \u010dekati RP-Announce poruke. Tek kada prona\u0111e bar jedan RP, po\u010de\u0107e slati 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 \/>\nNa taj na\u010din, \u010dim obi\u010dni ruteri (PIM RP Listener) prime ovu poruku, zna\u0107e gde da tra\u017ee RP.<br \/>\nJedan od glavnih problema Auto-RP-a je to \u0161to da bi primali RP-Announce i RP-Discovery poruke, potrebno je slati PIM Join na adrese 224.0.1.39-40, a da bi se to u\u010dinilo, potrebno je znati gde se nalazi RP. Klasi\u010dan problem koko\u0161ke i jaja. Da bi se ovaj problem re\u0161io, osmi\u0161ljen je re\u017eim PIM Sparse-Dense-Mode. Ako ruter ne zna RP, onda radi u re\u017eimu Dense-mode, ako zna, onda u re\u017eimu Sparse-mode. Kada su na interfejsima obi\u010dnih rutera pode\u0161eni PIM Sparse-mode i komanda ip pim autorp listener, ruter \u0107e raditi u re\u017eimu Dense-mode samo za multicast direktno Auto-RP protokola (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nOva funkcija radi sli\u010dno kao Auto-RP. Svaki RP \u0161alje poruku mapping agentu, koji prikuplja mapiranje informacije i zatim obave\u0161tava sve ostale rutere. Opisa\u0107emo proces na sli\u010dan na\u010din kao Auto-RP:<br \/>\n1) \u010cim postavimo R3 kao kandidata za RP, komandom:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nR3 ne\u0107e raditi ni\u0161ta, da bi po\u010deo slati specijalne poruke, prvo mora prona\u0107i mapping agent-a. Tako dolazimo do drugog koraka.<br \/>\n2) Postavljamo R2 kao mapping agent:<\/p>\n<blockquote><p>ip pim bsr-kandidat loopback 0<\/p><\/blockquote>\n<p>\nR2 zapo\u010dinje slanje PIM Bootstrap poruka, u kojima se predstavlja kao 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 \/>\nOva poruka se \u0161alje na adresu 224.0.0.13, koju PIM protokol koristi i za druge svoje poruke. Ona se \u0161alje u svim smjerovima, stoga nema problema s koko\u0161i i jajeta, kao \u0161to je bilo u Auto-RP.<br \/>\n3) \u010cim RP primi poruku od BSR usmjeriva\u010da, odmah \u0107e poslati unicast poruku na adresu BSR usmjeriva\u010da:<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 \/>\nNakon toga, BSR, dobiv\u0161i informacije o RP-u, poslat \u0107e ih multicastom na adresu 224.0.0.13, koju slu\u0161aju svi PIM usmjeriva\u010di. Zato ne postoji ekvivalentna naredba <i>ip pim autorp listener<\/i> za obi\u010dne usmjeriva\u010de u BSR-u.<br \/>\n<b>Anycast RP s Multicast Source Discovery Protocol (MSDP).<\/b><br \/>\nAuto-RP i BSR omogu\u0107uju nam raspodjelu optere\u0107enja na RP na sljede\u0107i na\u010din: Svaka multicast grupacija ima samo jednog aktivnog RP-a. Nije mogu\u0107e raspodijeliti optere\u0107enje za jednu multicast grupu izme\u0111u vi\u0161e RP-ova. MSDP to omogu\u0107ava dodjeljuju\u0107i RP usmjeriva\u010dima istu IP adresu s maskom 255.255.255.255. MSDP saznaje informacije putem jednog od metoda: statike, Auto-RP ili 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 slici imamo Auto-RP konfiguraciju s MSDP-om. Oba RP-a su konfigurirana s IP adresom 172.16.1.1\/32 na Loopback 1 su\u010delju i koriste se za sve grupe. Tijekom RP-Announce oba usmjeriva\u010da govore o sebi, pozivaju\u0107i se na ovu adresu. Auto-RP mapping agent, dobiv\u0161i informacije, \u0161alje RP-Discovery o RP-u s adresom 172.16.1.1\/32. O mre\u017ei 172.16.1.1\/32, obavje\u0161tavamo usmjeriva\u010de putem IGP-a. Tako, PIM usmjeriva\u010di tra\u017ee ili registriraju tokove s RP-a, koji je ozna\u010den kao next-hop u ruti do mre\u017ee 172.16.1.1\/32. Sam protokol MSDP je osmi\u0161ljen za RP-ove, kako bi razmjenjivali poruke o informacijama o multicastu.<br \/>\nRazmotrimo sljede\u0107u topologiju:<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 emitira promet na adresu 238.38.38.38 i za to za sada zna samo RP-R1. Evo, Switch7 i Switch8 su zatra\u017eili ovu grupu. Usmjeriva\u010di R5 i R4 \u0107e poslati PIM Join na R1 i R3, redom. Za\u0161to? Ruta do 13.13.13.13 kod R5 \u0107e se referirati na R1 prema IGP metri, kao i kod R4.<br \/>\nRP-R1 zna o toku i po\u010dne \u0107e ga emitirati prema R5, dok za R4 ni\u0161ta o tome nije poznato, budu\u0107i da mu R1 to ne mo\u017ee slati bez razloga. Zato je potreban MSDP. Konfiguriramo ga 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>\nOni \u0107e uspostaviti sesiju izme\u0111u sebe i pri primanju bilo kojeg toka \u0107e obavijestiti svog susjeda RP-a o tome.<br \/>\nRP-R1 \u0107e odmah nakon primanja struje od Switch6 poslati unicast MSDP Source-Active poruku, koja \u0107e sadr\u017eavati informacije poput (S, G) \u2014 informacije o izvoru i odredi\u0161tu multicast-a. Sada kada RP-R3 zna da takav izvor kao Switch6 postoji, prilikom primanja zahtjeva od R4 za tu struju, poslat \u0107e PIM Join prema Switch6, vodi se na osnovu tablice usmjeravanja. Stoga \u0107e R1, nakon primanja takvog PIM Joina, po\u010deti slati promet prema RP-R3.<br \/>\nMSDP radi putem TCP-a, RP me\u0111usobno \u0161alju keepalive poruke za provjeru ispravnosti. Tajmer iznosi 60 sekundi.<br \/>\nFunkcija razdvajanja MSDP peerova u razli\u010dite domene ostaje nejasna, jer se u Keepalive i SA porukama ne navodi pripadnost odre\u0111enoj domeni. Tako\u0111er, u ovoj topologiji testirana je konfiguracija sa razli\u010ditim domenskim nazivima \u2014 nije bilo razlike u radu. <br \/>\nAko netko mo\u017ee pojasniti, rado \u0107u pro\u010ditati u komentarima.<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.4 - 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\/hr\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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\udd47Principi rada PIM protokola | ProHoster","description":"PIM protokol je skup protokola za prijenos multicast-a u mre\u017ei izme\u0111u usmjeriva\u010da. Odnosi susjedstva se uspostavljaju sli\u010dno kao u slu\u010daju dinami\u010dkih protokola usmjeravanja.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}