{"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\/da\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Principles of PIM protocol operation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>PIM-protokollen er en r\u00e6kke protokoller til overf\u00f8rsel af multicast i netv\u00e6rk mellem routere. Naboskaberne opbygges ligesom ved dynamiske routingprotokoller. PIMv2 sender hvert 30. sekund Hello-beskeder til den reserverede multicast-adresse 224.0.0.13 (All-PIM-Routers). Beskeden indeholder Hold Timers \u2014 normalt lig med 3.5*Hello Timer, hvilket betyder 105 sekunder som standard.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM har to hoveddriftsformer \u2014 Dense og Sparse mode. Lad os begynde med Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Source-Based Distribution Trees.<\/b><br \/>\nDense-mode er hensigtsm\u00e6ssigt at anvende i tilf\u00e6lde af et stort antal klienter i forskellige multicast-grupper. N\u00e5r en router modtager multicast-trafik, kontrollerer den f\u00f8rst trafikreglen RPF. RPF-reglen bruges til at kontrollere kilde for multicast med den unicast routingtabel. Det er n\u00f8dvendigt, at trafikken kommer ind p\u00e5 den interface, som den p\u00e5g\u00e6ldende v\u00e6rt er skjult bag if\u00f8lge unicast routingtabellen. Denne mekanisme l\u00f8ser problemet med loop-dannelse ved overf\u00f8rsel af multicast.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 finder ud af kilden til multicast (Source IP) gennem multicast-beskeden og kontrollerer to str\u00f8mme fra R1 og R2 i sin unicast routingtabel. Str\u00f8mmen fra den interface, som routingtabellen peger p\u00e5 (R1 til R3), vil blive sendt videre, mens str\u00f8mmen fra R2 vil blive droppet, da det skal sende pakker gennem S0\/1 for at n\u00e5 kildemilj\u00f8et.<br \/>\nHvad hvis du har to \u00e6kvivalente ruter med samme metrik? I dette tilf\u00e6lde vil routeren v\u00e6lge baseret p\u00e5 next-hop for de p\u00e5g\u00e6ldende ruter. Den med den h\u00f8jeste IP-adresse vinder. Hvis det er n\u00f8dvendigt at \u00e6ndre denne adf\u00e6rd, kan man bruge ECMP. L\u00e6s mere. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">her<\/a><\/noindex>.<br \/>\nEfter kontrol af RPF-reglen sender routeren multicast-pakken til alle sine PIM-naboer, undtagen den, som pakken blev modtaget fra. De andre PIM-routiere gentager denne proces. Stien, som multicast-pakken har taget fra kilden til de endelige modtagere, danner et tr\u00e6, der kaldes \u2014 source-based distribution tree, shortest-path tree (SPT), source tree. Tre forskellige navne, v\u00e6lg et.<br \/>\nHvordan l\u00f8ser man sp\u00f8rgsm\u00e5let om, at nogle routere ikke har brug for en bestemt multicast-str\u00f8m, og der ikke er nogen til at sende den, men den overordnede router sender den? Til dette er Prune-mekanismen opfundet. <br \/>\n<b>Prune Message.<\/b><br \/>\nFor eksempel vil R2 forts\u00e6tte med at sende multicast til R3, selvom R3 afviser det i henhold til RPF-reglen. Hvorfor belaste kanalen? R3 sender en PIM Prune-besked, og R2, n\u00e5r den modtager denne besked, fjerner interface S0\/1 fra listen over udg\u00e5ende interfaces for denne str\u00f8m, listen over interfaces, som skal sende denne trafik. <\/p>\n<blockquote><p>F\u00f8lgende er en mere formel definition af en PIM Prune-besked:<br \/>\nPIM Prune-beskeden sendes af \u00e9n router til en anden router for at f\u00e5 den anden router til at fjerne den forbindelse, hvorp\u00e5 Prune modtages fra et bestemt (S,G) SPT.<\/p><\/blockquote>\n<p>\nEfter modtagelsen af Prune-beskeden s\u00e6tter R2 Prune-timeren til 3 minutter. Efter tre minutter vil den begynde at sende trafik igen, indtil den modtager endnu en Prune-besked. Dette g\u00e6lder i PIMv1.<br \/>\nI PIMv2 er der tilf\u00f8jet en State Refresh-timer (som standard 60 sekunder). S\u00e5 snart der er sendt en Prune-besked fra R3, startes denne timer p\u00e5 R3. N\u00e5r timeren udl\u00f8ber, vil R3 sende en State Refresh-besked, der nulstiller R2's 3-minutters Prune-timer for denne gruppe. <br \/>\n\u00c5rsager til at sende en Prune-besked:<\/p>\n<ul>\n<li> N\u00e5r multicast-pakken ikke bestod RPF-kontrollen.<\/li>\n<li> N\u00e5r der ikke er lokalt tilsluttede klienter, der har anmodet om den multicast-gruppe (IGMP Join), og der ikke er PIM-naboer, som multicast-trafik kan sendes til (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Graft Message.<\/b><br \/>\nLad os forestille os, at R3 ikke ville have trafik fra R2, sendte Prune og modtog multicast fra R1. Men pludselig gik forbindelsen mellem R1-R3 ned, og R3 er uden multicast. Man kan vente 3 minutter, indtil R2's Prune-timer udl\u00f8ber. At vente 3 minutter er l\u00e6nge, for ikke at skulle vente, er det n\u00f8dvendigt at sende en besked, der \u00f8jeblikkeligt vil fjerne dette interface S0\/1 p\u00e5 R2 fra det pruned-tilstand. En s\u00e5dan besked vil v\u00e6re Graft-beskeden. Efter modtagelsen af Graft-beskeden vil R2 sende en Graft-ACK som svar.<br \/>\n<b>Prune Override.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zfo0Dx5.png\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nLad os se p\u00e5 denne ordning. R1 sender multicast til en segment med to routere. R3 modtager og sender trafik, R2 modtager, men der er ingen at sende trafik til. Han sender en Prune-besked til R1 i dette segment. R1 skal fjerne Fa0\/0 fra listen og stoppe med at sende til dette segment, men hvad med R3? R3 befinder sig i den samme segment, har ogs\u00e5 modtaget denne Prune-besked og forst\u00e5r hele alvoren i situationen. F\u00f8r R1 stopper med at sende, s\u00e6tter han en timer p\u00e5 3 sekunder og stopper med at sende efter 3 sekunder. 3 sekunder \u2014 det er pr\u00e6cis den tid, R3 har til ikke at miste sin multicast. Derfor sender R3 s\u00e5 hurtigt som muligt en Pim Join-besked for denne gruppe, og R1 overvejer ikke l\u00e6ngere at stoppe med at sende. Om Join-beskederne nedenfor.<br \/>\n<b>Assert-besked.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nForestil dig en situation, hvor to routere sender i \u00e9t netv\u00e6rk. De modtager den samme str\u00f8m fra kilden, og begge sender den til et netv\u00e6rk via interface e0. Derfor skal de afg\u00f8re, hvem der bliver den eneste afsender for dette netv\u00e6rk. Det g\u00f8res ved hj\u00e6lp af Assert-beskeder. N\u00e5r R2 og R3 opdager duplikation af multicast-trafik, det vil sige, at multicast, som de selv sender, ogs\u00e5 modtages p\u00e5 R2 og R3, forst\u00e5r routerne, at der er noget galt. I dette tilf\u00e6lde sender routerne Assert-beskeder, som inkluderer Administrative Distance og metrikken for ruten til kilden til multicast \u2014 10.1.1.10. Vinderne bestemmes s\u00e5ledes:<\/p>\n<ol>\n<li>Den med lavest AD.<\/li>\n<li>Hvis AD er lige, s\u00e5 den med lavest metrik.<\/li>\n<li>Hvis der stadig er ligestilling, s\u00e5 den med den h\u00f8jeste IP i det netv\u00e6rk, de sender denne multicast til.<\/li>\n<\/ol>\n<p>\nDen der vinder denne afstemning, bliver Designated Router. Til valg af DR bruges ogs\u00e5 Pim Hello. I begyndelsen af artiklen blev et PIM Hello-besked vist, hvor man kan se DR-feltet. Den med de h\u00f8jeste IP-adresser p\u00e5 denne forbindelse vinder.<br \/>\nNyttigt skema:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE-tabel.<\/b><br \/>\nEfter den indledende gennemgang af, hvordan PIM-protokollen fungerer, er det n\u00f8dvendigt at forst\u00e5, hvordan man arbejder med multicast-routingtabellen. I mroute-tabellen opbevares information om, hvilke streams der er blevet anmodet af kunderne, og hvilke streams der str\u00f8mmer fra multicast-serverne. <br \/>\nFor eksempel, ved modtagelse af IGMP Membership Report eller PIM Join p\u00e5 et interface, tilf\u00f8jes der en post af typen ( *, G ) til routingtabellen:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDenne post betyder, at der er modtaget en anmodning om trafik fra adressen 238.38.38.38. DC-flaget betyder, at multicast vil fungere i Dense mode, og C betyder, at modtageren er direkte tilsluttet routeren, det vil sige, at routeren har modtaget en IGMP Membership Report, samt PIM Join.<br \/>\nHvis der er en post af typen (S,G), betyder det, at vi har en multicast-str\u00f8m:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nI feltet S \u2014 192.168.1.11, har vi angivet IP-adressen for kilden til multicast, som vil blive kontrolleret af RPF-reglen. Hvis der er problemer, skal du f\u00f8rst tjekke unicast-tabellen for ruten til kilden. I Incoming Interface angives det interface, hvor multicast'en modtages. I unicast-routingtabellen skal ruten til kilden pege p\u00e5 det interface, der er angivet her. I Outgoing Interface angives, hvor multicast'en vil blive videresendt. Hvis det er tomt, betyder det, at routeren ikke har modtaget anmodninger om denne trafik. Du kan finde mere detaljerede oplysninger om alle flagene <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">her<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nSparse-mode-strategien er modsat Dense-mode. N\u00e5r Sparse-mode modtager multicast-trafik, vil den sende trafikken kun gennem de interfaces, hvor der har v\u00e6ret anmodninger om denne str\u00f8m, for eksempel Pim Join eller IGMP Report-meddelelser med anmodning om denne trafik.<br \/>\nLignende elementer i SM og DM:<\/p>\n<ul>\n<li> Naboskaber etableres ogs\u00e5 som i PIM DM.<\/li>\n<li> RPF-reglen g\u00e6lder.<\/li>\n<li> Valget af DR er det samme.<\/li>\n<li> Prune Overrides-mekanismen og Assert-beskederne er analoge.<\/li>\n<\/ul>\n<p>\nFor at kontrollere, hvem, hvor, og hvilken multicast-trafik der er brug for i netv\u00e6rket, er der behov for et f\u00e6lles informationscentrum. Dette centrum bliver vores Rendezvous Point (RP). Alle, der \u00f8nsker en bestemt multicast-trafik eller som er begyndt at modtage multicast-trafik fra kilden, sender det til RP.<br \/>\nN\u00e5r RP modtager multicast-trafikken, sender den den til de routere, der tidligere har anmodet om denne trafik. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nLad os forestille os en topologi, hvor RP er R3. S\u00e5 snart R1 modtager trafik fra S1, indkapsler det denne multicast-pakke i en unicast PIM Register-besked og sender den til RP. Hvordan ved den, hvem RP er? I dette tilf\u00e6lde er den statisk konfigureret, og vi vil tale om dynamisk konfiguration af RP senere. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP vil unders\u00f8ge, om der var information fra nogen, der \u00f8nskede at modtage denne trafik? Lad os antage, at der ikke var nogen. S\u00e5 sender RP et Register-Stop-besked til R1, hvilket betyder, at ingen \u00f8nsker denne multicast, registreringen er afvist. R1 vil ikke sende multicast. Men kilden til multicast vil fortsat sende den, s\u00e5 R1, efter at have modtaget Register-Stop, vil starte en Register-Suppression-timer p\u00e5 60 sekunder. 5 sekunder f\u00f8r denne timer udl\u00f8ber, vil R1 sende en tom Register-besked med Null-Register-bit (dvs. uden indkapslet multicast-pakke) mod RP. RP vil p\u00e5 sin side handle s\u00e5ledes:<\/p>\n<ul>\n<li> Hvis der ikke var nogen modtagere, vil han svare med en Register-Stop-besked.<\/li>\n<li> Hvis der er opst\u00e5et modtagere, vil han ikke svare p\u00e5 den. R1, der ikke har modtaget afvisning p\u00e5 sin registrering inden for 5 sekunder, vil v\u00e6re glad og sende en Register-besked med indkapslet multicast til RP.<\/li>\n<\/ul>\n<p>\nVi har forh\u00e5bentlig klaret, hvordan multicast n\u00e5r frem til RP; nu vil vi fors\u00f8ge at besvare sp\u00f8rgsm\u00e5let om, hvordan RP leverer trafikken til modtagerne. Her er det n\u00f8dvendigt at introducere et nyt begreb - root-path tree (RPT). RPT er et tr\u00e6 med rod i RP, der vokser mod modtagerne og forgrener sig ved hver PIM-SM-router. RP skaber det ved at modtage PIM Join-beskeder og tilf\u00f8jer en ny gren til tr\u00e6et. Og s\u00e5dan g\u00f8r hver underliggende router. Den overordnede regel ser s\u00e5ledes ud:<\/p>\n<ul>\n<li> N\u00e5r en PIM-SM-router modtager en PIM Join-besked p\u00e5 en hvilken som helst interface, undtagen den interface, hvor RP er skjult, tilf\u00f8jer den en ny gren til tr\u00e6et.<\/li>\n<li> En gren tilf\u00f8jes ogs\u00e5, n\u00e5r en PIM-SM-router modtager en IGMP Membership Report fra en direkte tilsluttet v\u00e6rt. <\/li>\n<\/ul>\n<p>\nLad os forestille os, at vi har en multicast-klient p\u00e5 router R5 til gruppe 228.8.8.8. S\u00e5 snart R5 modtager en IGMP Membership Report fra v\u00e6rten, sender R5 en PIM Join mod RP og tilf\u00f8jer selv interfacet, der peger mod v\u00e6rten, til tr\u00e6et. Derefter modtager R4 PIM Join fra R5, tilf\u00f8jer interfacet Gi0\/1 til tr\u00e6et og sender PIM Join mod RP. Endelig modtager RP (R3) PIM Join og tilf\u00f8jer Gi0\/0 til tr\u00e6et. P\u00e5 denne m\u00e5de g\u00f8r vi modtagerregistreringen af multicast. Vi bygger et tr\u00e6 med roden R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nEfter dette vil PIM Join blive sendt til R1, og R1 vil begynde at sende multicast trafik. Det er vigtigt at bem\u00e6rke, at hvis v\u00e6rten anmoder om trafik, f\u00f8r multicast-afsendelsen er begyndt, s\u00e5 vil RP ikke sende PIM Join og overhovedet ikke sende noget til R1.<br \/>\nHvis v\u00e6rten pludselig stopper med at ville modtage multicast, s\u00e5 snart RP modtager PIM Prune p\u00e5 interface Gi0\/0, vil den straks sende PIM Register-Stop direkte til R1, og derefter PIM Prune meddelelse via interface Gi0\/1. PIM Register-Stop sendes unicast til den adresse, hvorfra PIM Register blev modtaget.<br \/>\nSom vi n\u00e6vnte tidligere, s\u00e5 snart routeren sender PIM Join til en anden, for eksempel R5 til R4, s\u00e5 bliver der tilf\u00f8jet en post p\u00e5 R4:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nOg der startes en timer, som R5 konstant skal resettere ved at sende PIM Join meddelelser, ellers vil R4 udelukke den fra outgoing list. R5 vil sende PIM Join meddelelser hver 60. gang.<br \/>\n<b>Shortest-Path Tree Switchover.<\/b><br \/>\nVi vil tilf\u00f8je et interface mellem R1 og R5, og se hvordan trafikken vil flyde i denne topologi. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nLad os antage, at trafikken blev sendt og modtaget efter den gamle ordning R1-R2-R3-R4-R5, og nu har vi tilsluttet og konfigureret et interface mellem R1 og R5.<br \/>\nFor det f\u00f8rste vil unicast routing tabellen p\u00e5 R5 blive ombygget, og nu n\u00e5s netv\u00e6rket 192.168.1.0\/24 gennem interface R5 Gi0\/2. Nu, n\u00e5r R5 modtager multicast p\u00e5 interface Gi0\/1, forst\u00e5r den, at RPF-reglen ikke er opfyldt, og det ville v\u00e6re mere logisk at modtage multicast p\u00e5 Gi0\/2. Den skal frakoble sig fra RPT og opbygge et kortere tr\u00e6, der kaldes Shortest-Path Tree (SPT). For dette sender den via Gi0\/2 PIM Join til R1, og R1 begynder ogs\u00e5 at sende multicast gennem Gi0\/2. Nu skal R5 afmelde sig fra RPT for ikke at modtage to kopier. For dette sender den en Prune meddelelse angivende IP-adressen p\u00e5 kilden og inds\u00e6tter et specielt bit \u2014 RPT-bit. Det betyder, at jeg ikke \u00f8nsker trafik sendt til mig, da jeg har et bedre tr\u00e6 her. RP sender ogs\u00e5 PIM Prune meddelelser mod R1, men sender ikke Register-Stop meddelelser. En anden funktion: R5 vil nu konstant sende PIM Prune til RP, da R1 forts\u00e6tter med at sende PIM Register til RP hvert minut. RP vil, indtil der er nye interesserede i denne trafik, svare ham med afslag. R5 informerer RP om, at den fortsat modtager multicast gennem SPT.<br \/>\n<b>Dynamisk s\u00f8gning af RP. <br \/>\nAuto-RP.<\/b><br \/>\nDenne teknologi er propriet\u00e6r fra Cisco og er ikke s\u00e6rlig popul\u00e6r, men den er stadigv\u00e6k i brug. Auto-RP arbejder i to hovedfaser:<br \/>\n1) RP sender RP-Announce beskeder til den reserverede adresse \u2014 224.0.1.39, og erkl\u00e6rer sig selv som RP enten for alle eller for specifikke grupper. Denne besked sendes hvert minut.<br \/>\n2) En RP mapping agent er n\u00f8dvendig, som sender RP-Discovery beskeder med angivelse af, hvilke grupper der skal lytte til hvilken RP. Det er fra denne besked, almindelige PIM-routere vil bestemme deres RP. Mapping agenten kan v\u00e6re enten den samme RP-router eller en separat PIM-router. RP-Discovery sendes til adressen 224.0.1.40 med et interval p\u00e5 et minut.<br \/>\nLad os se n\u00e6rmere p\u00e5 processen:<br \/>\nIndstil R3 som RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 som mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nOg vi vil forvente RP via Auto-RP p\u00e5 alle de andre:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nS\u00e5 snart vi indstiller R3, vil den begynde at sende RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nOg R2, efter at v\u00e6re blevet indstillet som mapping agent, vil begynde at vente p\u00e5 RP-Announce beskeder. Kun n\u00e5r den finder mindst \u00e9n RP, vil den begynde at sende RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nP\u00e5 den m\u00e5de, n\u00e5r almindelige routere (PIM RP Listener) modtager disse beskeder, ved de, hvor de skal lede efter RP.<br \/>\nEt af hovedproblemerne med Auto-RP er, at for at modtage RP-Announce og RP-Discovery beskeder skal der sendes PIM Join til adresserne 224.0.1.39-40, og for at sende, skal man vide, hvor RP'en befinder sig. Det klassiske problem med kylling og \u00e6g. For at l\u00f8se dette problem blev PIM Sparse-Dense-Mode opfundet. Hvis routeren ikke kender RP, arbejder den i Dense-mode, hvis den g\u00f8r, s\u00e5 i Sparse-mode. N\u00e5r PIM Sparse-mode er indstillet p\u00e5 de almindelige routeres interfaces og kommandoen ip pim autorp listener er aktiveret, vil routeren fungere i Dense-mode kun for multicast af selve Auto-RP protokollen (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nDenne funktion fungerer p\u00e5 en m\u00e5de som Auto-RP. Hver RP sender en besked til mapping agenten, som indsamler mapping information og fort\u00e6ller derefter alle de andre routere. Lad os beskrive processen p\u00e5 samme m\u00e5de som Auto-RP:<br \/>\n1) S\u00e5 snart vi indstiller R3 som kandidat til at v\u00e6re RP, med kommandoen:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nVil R3 ikke g\u00f8re noget, for at begynde at sende specielle beskeder, skal den f\u00f8rst finde mapping agenten. Derfor g\u00e5r vi videre til det andet trin.<br \/>\n2) Indstil R2 som mapping agent:<\/p>\n<blockquote><p>ip pim bsr-kandidat loopback 0<\/p><\/blockquote>\n<p>\nR2 begynder at sende PIM Bootstrap beskeder, hvor den angiver sig selv som mapping agent:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDenne besked sendes til adressen 224.0.0.13, som PIM-protokollen ogs\u00e5 bruger til sine andre beskeder. Den sender dem i alle retninger, s\u00e5 der er ikke noget problem med h\u00f8nen og \u00e6gget, som med Auto-RP.<br \/>\n3) S\u00e5 snart RP modtager beskeden fra BSR-routeren, sender den straks en unicast-besked til adressen BSR-routeren:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDerefter vil BSR, efter at have modtaget informationen om RP, sende dem multicast til adressen 224.0.0.13, som alle PIM-routere lytter til. Derfor er der ikke et modstykke til kommandoen <i>ip pim autorp listener<\/i> for almindelige routere i BSR.<br \/>\n<b>Anycast RP med Multicast Source Discovery Protocol (MSDP).<\/b><br \/>\nAuto-RP og BSR g\u00f8r det muligt for os at fordele belastningen p\u00e5 RP som f\u00f8lger: Hver multicast-gruppe har kun \u00e9n aktiv RP. Det er ikke muligt at fordele belastningen for en enkelt multicast-gruppe p\u00e5 flere RP'er. MSDP g\u00f8r dette ved at tildele RP-routerne den samme ip-adresse med masken 255.255.255.255. MSDP f\u00e5r information ved hj\u00e6lp af en af metoderne: statisk, Auto-RP eller BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nP\u00e5 billedet har vi en Auto-RP konfiguration med MSDP. Begge RP'er er konfigureret med ip-adressen 172.16.1.1\/32 p\u00e5 Loopback 1-interfacet og bruges til alle grupper. Ved RP-announce fort\u00e6ller begge routere om sig selv, med henvisning til denne adresse. Auto-RP mapping agent, der modtager information, sender RP-Discovery om RP med adressen 172.16.1.1\/32. Om netv\u00e6rket 172.16.1.1\/32 fort\u00e6ller vi routerne ved hj\u00e6lp af IGP, og tilsvarende. Dermed anmoder PIM-routerne om eller registrerer str\u00f8mme fra den RP, der er angivet som next-hop til ruten til netv\u00e6rket 172.16.1.1\/32. Selve MSDP-protokollen er designet til RP'er, s\u00e5 de kan udveksle beskeder om information om multicast.<br \/>\nLad os overveje denne topologi:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Principles of PIM protocol operation\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 broadcaster trafik til adressen 238.38.38.38, og indtil videre kender kun RP-R1 til den. Nu har Switch7 og Switch8 anmodet om denne gruppe. Routerne R5 og R4 vil sende PIM Join til R1 og R3, henholdsvis. Hvorfor? Ruten til 13.13.13.13 hos R5 vil henvise til R1 efter IGP-metrik, ligesom hos R4.<br \/>\nRP-R1 kender til str\u00f8mmen og begynder at sende den mod R5, men R4 ved intet om den, da R1 ikke vil sende den bare s\u00e5dan. Derfor er MSDP n\u00f8dvendigt. Vi konfigurerer det p\u00e5 R1 og R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 p\u00e5 R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 p\u00e5 R3<\/p><\/blockquote>\n<p>\nDe vil etablere en session mellem hinanden, og ved modtagelse af en hvilken som helst str\u00f8m vil de informere om den til deres RP-nabo.<br \/>\nN\u00e5r RP-R1 modtager str\u00f8m fra Switch6, sender den straks en unicast MSDP Source-Active meddelelse, som indeholder informationstype (S, G) - oplysninger om kilde og destination for multicast. Nu, n\u00e5r RP-R3 ved, at der er en kilde som Switch6, vil den ved modtagelse af en anmodning fra R4 om denne str\u00f8m sende en PIM Join mod Switch6 baseret p\u00e5 routing-tabellen. Derfor vil R1, n\u00e5r den modtager denne PIM Join, begynde at sende trafik i retning af RP-R3.<br \/>\nMSDP fungerer over TCP, RP sender keepalive beskeder til hinanden for at kontrollere deres livskraft. Timeren er 60 sekunder.<br \/>\nFunktionen til at opdele MSDP-naboer i forskellige dom\u00e6ner forbliver uklar, da der i Keepalive og SA-beskederne ikke angives tilh\u00f8rsforhold til noget dom\u00e6ne. I denne topologi blev der ogs\u00e5 testet en konfiguration med angivelse af forskellige dom\u00e6ner - der var ingen forskel i driften. <br \/>\nHvis nogen kan bringe klarhed, vil jeg med gl\u00e6de l\u00e6se kommentarer.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450582\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33142","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Principperne for PIM-protokollens funktion | ProHoster","description":"PIM-protokollen er et s\u00e6t protokoller til transmission af multicast i netv\u00e6rk mellem routere. Nabo-relationer opbygges p\u00e5 samme m\u00e5de som for dynamiske routingprotokoller.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}