{"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\/it\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Principi di funzionamento del protocollo PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il protocollo PIM \u00e8 un insieme di protocolli per la trasmissione di multicast nelle reti tra router. Le relazioni di vicinato vengono stabilite in modo analogo a quanto avviene con i protocolli di routing dinamici. PIMv2 invia ogni 30 secondi messaggi Hello all'indirizzo multicast riservato 224.0.0.13 (All-PIM-Routers). Il messaggio contiene i Hold Timers, che di solito \u00e8 pari a 3,5 volte il Hello Timer, ossia 105 secondi per impostazione predefinita.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM utilizza due modalit\u00e0 di funzionamento principali: Dense e Sparse. Iniziamo con la modalit\u00e0 Dense. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Alberi di distribuzione basati su sorgente.<\/b><br \/>\nLa modalit\u00e0 Dense \u00e8 opportuno utilizzarla in caso di un gran numero di clienti di diversi gruppi multicast. Quando un router riceve il traffico multicast, controlla prima di tutto se il traffico rispetti la regola RPF. RPF \u00e8 una regola utilizzata per verificare la sorgente del multicast con la tabella di routing unicast. \u00c8 necessario che il traffico arrivi su quell'interfaccia che corrisponde a quel host secondo la tabella di routing unicast. Questo meccanismo risolve il problema della formazione di loop durante la trasmissione del multicast.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3, dal messaggio multicast, identificher\u00e0 la fonte del multicast (Source IP) e controller\u00e0 due flussi da R1 e R2 attraverso la sua tabella unicast. Il flusso dall'interfaccia indicata nella tabella (R1 verso R3) sar\u00e0 inoltrato, mentre il flusso da R2 sar\u00e0 scartato, poich\u00e9 per raggiungere la fonte multicast \u00e8 necessario inviare pacchetti tramite S0\/1.<br \/>\nCosa succede se hai due percorsi equivalenti con la stessa metrica? In questo caso, il router sceglier\u00e0 in base al next-hop di questi percorsi. Chi ha l'indirizzo IP pi\u00f9 alto avr\u00e0 la precedenza. Se \u00e8 necessario modificare questo comportamento, \u00e8 possibile utilizzare ECMP. Maggiori dettagli. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">qui<\/a><\/noindex>.<br \/>\nDopo aver verificato la regola RPF, il router invia il pacchetto multicast a tutti i suoi vicini PIM, ad eccezione di quello da cui \u00e8 stato ricevuto il pacchetto. Gli altri router PIM ripetono questo processo. Il percorso che il pacchetto multicast ha seguito dalla fonte ai destinatari finali forma un albero chiamato \u2014 source-based distribution tree, shortest-path tree (SPT), source tree. Tre nomi diversi, scegli quello che preferisci.<br \/>\nCome risolvere il problema di alcuni router che non ricevono un certo flusso multicast e non lo inviano a nessuno, mentre il router superiore lo invia. Per questo \u00e8 stato inventato il meccanismo Prune. <br \/>\n<b>Messaggio Prune.<\/b><br \/>\nAd esempio, R2 continuer\u00e0 a inviare multicast a R3, anche se R3, seguendo la regola RPF, lo scarta. Perch\u00e9 sovraccaricare il canale? R3 invia un messaggio PIM Prune e R2, al ricevimento di questo messaggio, rimuover\u00e0 l'interfaccia S0\/1 dalla lista (outgoing interface list) per questo flusso, la lista delle interfacce da cui inviare questo traffico. <\/p>\n<blockquote><p>Di seguito \u00e8 fornita una definizione pi\u00f9 formale di un messaggio PIM Prune:<br \/>\nIl messaggio PIM Prune \u00e8 inviato da un router a un secondo router per far s\u00ec che il secondo router rimuova il link su cui viene ricevuto il Prune da un particolare (S,G) SPT.<\/p><\/blockquote>\n<p>\nDopo il ricevimento del messaggio Prune, R2 imposta il timer Prune a 3 minuti. Dopo tre minuti inizier\u00e0 a inviare nuovamente il traffico, finch\u00e9 non riceve un altro messaggio Prune. Questo vale per PIMv1.<br \/>\nIn PIMv2 \u00e8 stato aggiunto un timer di State Refresh (di default 60 secondi). Una volta inviato il messaggio Prune da R3, questo timer viene avviato su R3. Al termine di questo timer, R3 invier\u00e0 un messaggio di State Refresh, che reimposter\u00e0 il timer Prune di 3 minuti su R2 per questo gruppo. <br \/>\nMotivi per l'invio del messaggio Prune:<\/p>\n<ul>\n<li> Quando un pacchetto multicast non supera il controllo RPF.<\/li>\n<li> Quando non ci sono client collegati localmente che hanno richiesto il gruppo multicast (IGMP Join) e non ci sono vicini PIM a cui inviare il traffico multicast (Interfaccia Non-Pruned).<\/li>\n<\/ul>\n<p>\n<b>Messaggio Graft.<\/b><br \/>\nImmaginiamo che R3 non volesse ricevere traffico da R2, inviando un Prune e ricevendo multicast da R1. Ma improvvisamente, la connessione tra R1 e R3 si interrompe e R3 rimane senza multicast. Si possono aspettare 3 minuti, finch\u00e9 il Prune Timer su R2 non scade. 3 minuti sono tanti, per non aspettare, \u00e8 necessario inviare un messaggio che toglie immediatamente l'interfaccia S0\/1 su R2 dallo stato pruned. Questo messaggio sar\u00e0 il messaggio Graft. Dopo aver ricevuto il messaggio Graft, R2 invier\u00e0 in risposta un 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=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nEsaminiamo questo schema. R1 trasmette multicast nella rete con due router. R3 riceve e trasmette il traffico, R2 riceve, ma non ha nessuno a cui trasmettere il traffico. Invia un messaggio Prune a R1 in questa rete. R1 deve rimuovere Fa0\/0 dall'elenco e smettere di trasmettere in questa rete, ma cosa succede a R3? R3 si trova nella stessa rete, ha ricevuto il messaggio Prune e ha capito la gravit\u00e0 della situazione. Prima che R1 smetta di trasmettere, imposta un timer di 3 secondi e smetter\u00e0 di trasmettere tra 3 secondi. 3 secondi: questo \u00e8 il tempo che R3 ha per non perdere il suo multicast. Pertanto, R3 invia il messaggio Pim Join per questo gruppo il pi\u00f9 rapidamente possibile e R1 non pensa pi\u00f9 a smettere di trasmettere. Di seguito sono riportati i messaggi Join.<br \/>\n<b>Messaggio di Asserzione.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nImmagina una situazione in cui due router trasmettono nella stessa rete. Ricevono lo stesso flusso da una sorgente e entrambi lo inviano nella stessa rete attraverso l'interfaccia e0. Pertanto, devono determinare chi sar\u00e0 l'unico emittente per quella rete. A tal fine vengono utilizzati i messaggi Assert. Quando R2 e R3 rilevano la duplicazione del traffico multicast, ovvero quando R2 e R3 ricevono un multicast che loro stessi stanno trasmettendo, i router capiscono che c'\u00e8 qualcosa di strano. I router inviano quindi messaggi Assert, che includono la Administrative Distance e la metrica del percorso utilizzato per raggiungere la sorgente multicast \u2014 10.1.1.10. Il vincitore viene determinato in questo modo:<\/p>\n<ol>\n<li>Quello con l'AD pi\u00f9 basso.<\/li>\n<li>Se l'AD \u00e8 uguale, vince chi ha la metrica pi\u00f9 bassa.<\/li>\n<li>Se c'\u00e8 ancora parit\u00e0, vince chi ha l'IP pi\u00f9 alto nella rete in cui trasmettono questo multicast.<\/li>\n<\/ol>\n<p>\nIl router che vince questa votazione diventa il Designated Router. Per la selezione del DR vengono utilizzati anche i messaggi Pim Hello. All'inizio dell'articolo \u00e8 stato mostrato un messaggio PIM Hello, dove \u00e8 possibile notare il campo DR. Vince chi ha l'IP pi\u00f9 alto su questo link.<br \/>\nTabella utile:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE Table.<\/b><br \/>\nDopo una prima analisi del funzionamento del protocollo PIM, dobbiamo approfondire come operare con la tabella di instradamento multicast. Nella tabella mroute sono memorizzate le informazioni su quali flussi sono stati richiesti dai client e quali flussi provengono dai server multicast. <br \/>\nAd esempio, quando si riceve un IGMP Membership Report o un PIM Join su un certo interfaccia, viene aggiunta alla tabella di instradamento una voce di tipo (*, G):<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nQuesta voce indica che \u00e8 stata ricevuta una richiesta di traffico dall'indirizzo 238.38.38.38. Il flag DC indica che il multicast operer\u00e0 in modalit\u00e0 Dense e C indica che il ricevente \u00e8 direttamente connesso al router, ovvero il router ha ricevuto un IGMP Membership Report e un PIM Join.<br \/>\nSe c'\u00e8 una voce di tipo (S,G), significa che abbiamo un flusso multicast:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNel campo S \u2014 192.168.1.11, abbiamo registrato l'indirizzo IP della fonte multicast, che sar\u00e0 verificato dalla regola RPF. In caso di problemi, la prima cosa da controllare \u00e8 la tabella unicast per la rotta verso la fonte. Nel campo Interfaccia in Entrata viene indicata l'interfaccia alla quale arriva il multicast. Nella tabella di routing unicast, la rotta verso la fonte deve riferirsi all'interfaccia specificata qui. Nell'Interfaccia in Uscita si indica dove sar\u00e0 indirizzato il multicast. Se \u00e8 vuota, significa che non ci sono state richieste per questo traffico al router. Ulteriori informazioni su tutti i flag sono disponibili. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">qui<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nLa strategia Sparse-mode \u00e8 opposta alla Dense-mode. Quando la Sparse-mode riceve traffico multicast, invier\u00e0 il traffico solo attraverso le interfacce dove ci sono state richieste per quel flusso, ad esempio messaggi Pim Join o IGMP Report con richieste per quel traffico.<br \/>\nElementi simili in SM e DM:<\/p>\n<ul>\n<li> Le relazioni di vicinato vengono costruite come in PIM DM.<\/li>\n<li> La regola RPF \u00e8 attiva.<\/li>\n<li> La scelta del DR \u00e8 simile.<\/li>\n<li> Il meccanismo Prune Overrides e i messaggi Assert sono analoghi.<\/li>\n<\/ul>\n<p>\nPer monitorare a chi, dove e quale traffico multicast \u00e8 necessario nella rete, \u00e8 necessario un centro informativo generale. Questo centro sar\u00e0 il Rendezvous Point (RP). Tutti coloro che desiderano un traffico multicast o chiunque inizi a ricevere traffico multicast da una sorgente, lo invia al RP.<br \/>\nQuando il RP riceve il traffico multicast, lo inoltra ai router che lo hanno richiesto in precedenza. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nImmaginiamo una topologia in cui il RP sia R3. Non appena R1 riceve traffico da S1, incapsula questo pacchetto multicast in un messaggio PIM Register unicast e lo invia al RP. Come sa chi \u00e8 il RP? In questo caso, \u00e8 configurato staticamente, ma parleremo della configurazione dinamica del RP pi\u00f9 avanti. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP verificher\u00e0 se ci fosse stata qualche informazione da parte di qualcuno che desiderava ricevere questo traffico. Supponiamo di no. In tal caso, RP invier\u00e0 a R1 un messaggio PIM Register-Stop, che significa che nessuno \u00e8 interessato a questo multicast, la registrazione \u00e8 stata rifiutata. R1 non invier\u00e0 multicast. Tuttavia, la fonte host del multicast continuer\u00e0 a trasmetterlo, quindi R1, dopo aver ricevuto Register-Stop, avvier\u00e0 un timer di soppressione della registrazione, impostato a 60 secondi. Cinque secondi prima della scadenza di questo timer, R1 invier\u00e0 un messaggio Register vuoto con il bit Null-Register (cio\u00e8 senza pacchetto multicast incapsulato) verso RP. RP agir\u00e0 nel seguente modo:<\/p>\n<ul>\n<li> Se non ci sono destinatari, risponder\u00e0 con un messaggio Register-Stop.<\/li>\n<li> Se compaiono destinatari, non risponder\u00e0 in alcun modo. R1, non ricevendo rifiuto alla sua registrazione entro 5 secondi, si rallegrer\u00e0 e invier\u00e0 un messaggio Register con multicast incapsulato a RP.<\/li>\n<\/ul>\n<p>\nAbbiamo capito come il multicast raggiunge il RP, ora cerchiamo di rispondere alla domanda su come il RP porta il traffico ai destinatari. Qui \u00e8 necessario introdurre un nuovo concetto: il root-path tree (RPT). L'RPT \u00e8 un albero con radice nel RP, che cresce verso i destinatari, ramificandosi su ogni router PIM-SM. Il RP lo crea ricevendo i messaggi PIM Join e aggiunge un nuovo ramo all'albero. E cos\u00ec fa ogni router sottostante. La regola generale \u00e8 la seguente:<\/p>\n<ul>\n<li> Quando un router PIM-SM riceve un messaggio PIM Join su un'interfaccia, ad eccezione dell'interfaccia dietro la quale si nasconde il RP, aggiunge un nuovo ramo all'albero.<\/li>\n<li> Un ramo viene aggiunto anche quando un router PIM-SM riceve un IGMP Membership Report da un host a cui \u00e8 direttamente connesso. <\/li>\n<\/ul>\n<p>\nImmaginiamo di avere un client multicast sul router R5 per il gruppo 228.8.8.8. Non appena R5 riceve un IGMP Membership Report dall'host, invia un PIM Join verso l'RP e aggiunge l'interfaccia che guarda verso l'host all'albero. Successivamente, R4 riceve un PIM Join da R5, aggiunge l'interfaccia Gi0\/1 all'albero e invia un PIM Join verso l'RP. Infine, l'RP (R3) riceve il PIM Join e aggiunge Gi0\/0 all'albero. Cos\u00ec si ottiene la registrazione del ricevitore multicast. Viene costruito un albero con la radice R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nDopo di ci\u00f2, verr\u00e0 inviato un PIM Join a R1 e R1 inizier\u00e0 a inviare traffico multicast. \u00c8 importante notare che, se un host ha richiesto traffico prima che iniziasse la trasmissione multicast, l'RP non invier\u00e0 un PIM Join e in generale non invier\u00e0 nulla verso R1.<br \/>\nSe durante l'invio del multicast, l'host smette di volerlo ricevere, non appena l'RP riceve un PIM Prune sull'interfaccia Gi0\/0, invier\u00e0 immediatamente un PIM Register-Stop direttamente a R1 e poi un messaggio PIM Prune tramite l'interfaccia Gi0\/1. Il PIM Register-Stop viene inviato come unicast all'indirizzo da cui \u00e8 stato ricevuto il PIM Register.<br \/>\nCome abbiamo detto in precedenza, una volta che il router invia il PIM Join a un altro, ad esempio R5 a R4, viene aggiunta una voce su R4:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nE si avvia un timer, il quale deve essere costantemente resettato da R5 inviando messaggi PIM Join, altrimenti R4 lo escluder\u00e0 dall'elenco in uscita. R5 invier\u00e0 messaggi PIM Join ogni 60 secondi.<br \/>\n<b>Commutazione dell'albero del percorso pi\u00f9 breve.<\/b><br \/>\nAggiungeremo un'interfaccia tra R1 e R5 e osserveremo come fluir\u00e0 il traffico in questa topologia. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSupponiamo che il traffico venisse inviato e ricevuto secondo il vecchio schema R1-R2-R3-R4-R5 e ora abbiamo collegato e configurato un'interfaccia tra R1 e R5.<br \/>\nPer prima cosa, la nostra tabella di instradamento multicast si \u00e8 ristrutturata su R5 e ora la rete 192.168.1.0\/24 \u00e8 raggiungibile attraverso l'interfaccia R5 Gi0\/2. Ora R5, ricevendo multicast sull'interfaccia Gi0\/1, comprende che la regola RPF non \u00e8 soddisfatta e sarebbe pi\u00f9 logico ricevere multicast su Gi0\/2. Deve disconnettersi da RPT e costruire un albero pi\u00f9 corto, chiamato Shortest-Path Tree (SPT). A questo scopo, invia un PIM Join a R1 tramite Gi0\/2 e R1 inizia a trasmettere multicast anche su Gi0\/2. Ora R5 deve disiscriversi da RPT per non ricevere due copie. Per questo, invia un messaggio Prune indicando l'indirizzo IP della sorgente e inserendo un bit speciale \u2014 RPT-bit. Questo significa che non deve inviarmi traffico, ho un albero migliore qui. RP invia anche messaggi PIM Prune verso R1, ma non invia un messaggio Register-Stop. Un'altra caratteristica: R5 ora continuer\u00e0 a inviare PIM Prune a RP, poich\u00e9 R1 continua a inviare PIM Register a RP ogni minuto. RP, finch\u00e9 non ci saranno nuovi richiedenti di questo traffico, risponder\u00e0 rifiutando. R5 informa RP che continua a ricevere multicast tramite SPT.<br \/>\n<b>Ricerca dinamica di RP. <br \/>\nAuto-RP.<\/b><br \/>\nQuesta tecnologia \u00e8 proprietaria di Cisco e non \u00e8 molto popolare, ma \u00e8 ancora attiva. Il funzionamento di Auto-RP si basa su due fasi principali:<br \/>\n1) L'RP invia messaggi RP-Announce all'indirizzo riservato \u2014 224.0.1.39, annunciando se stesso come RP per tutti o per gruppi specifici. Questo messaggio viene inviato ogni minuto.<br \/>\n2) \u00c8 necessario un RP mapping agent che invii messaggi RP-Discovery specificando per quali gruppi quale RP deve essere ascoltato. I normali router PIM determineranno il loro RP da questo messaggio. Il mapping agent pu\u00f2 essere sia il router RP stesso che un altro router PIM. RP-Discovery viene inviato all'indirizzo 224.0.1.40 con un timer di un minuto.<br \/>\nApprofondiamo il processo:<br \/>\nConfiguriamo R3 come RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 come mapping agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nE sugli altri aspetti aspetteremo l'RP tramite Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nNon appena configureremo R3, inizier\u00e0 a inviare RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nE R2, dopo essere stato configurato come mapping agent, inizier\u00e0 ad attendere i messaggi RP-Announce. Solo quando trover\u00e0 almeno un RP, inizier\u00e0 a inviare RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nQuindi, non appena i normali router (PIM RP Listener) ricevono questo messaggio, sapranno dove cercare il RP.<br \/>\nUno dei problemi principali di Auto-RP \u00e8 che, per ricevere messaggi RP-Announce e RP-Discovery, \u00e8 necessario inviare PIM Join agli indirizzi 224.0.1.39-40, e per farlo, bisogna sapere dove si trova il RP. \u00c8 il classico problema dell'uovo e della gallina. Per risolvere questo problema, \u00e8 stata ideata la modalit\u00e0 PIM Sparse-Dense. Se il router non conosce il RP, opera in modalit\u00e0 Dense-mode; se lo conosce, in modalit\u00e0 Sparse-mode. Quando le interfacce dei normali router sono configurate in PIM Sparse-mode con il comando ip pim autorp listener, il router operer\u00e0 in modalit\u00e0 Dense-mode solo per il multicast relativo direttamente al protocollo Auto-RP (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nQuesta funzione funziona in modo simile ad Auto-RP. Ogni RP invia un messaggio all'agent di mapping, che raccoglie le informazioni di mapping e successivamente le comunica a tutti gli altri router. Descriveremo il processo in modo analogo a Auto-RP:<br \/>\n1) Non appena configuriamo R3 come candidato a essere RP, con il comando:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nR3 non far\u00e0 nulla. Per iniziare a inviare messaggi speciali, deve prima trovare un agent di mapping. Passiamo quindi al secondo passaggio.<br \/>\n2) Configuriamo R2 come agent di mapping:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 inizia a inviare messaggi PIM Bootstrap in cui si propone come agent di mapping:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nQuesto messaggio viene inviato all'indirizzo 224.0.0.13, che il protocollo PIM utilizza anche per altri suoi messaggi. Viene inviato in tutte le direzioni e quindi non c'\u00e8 il problema dell'uovo e della gallina, come avveniva con Auto-RP.<br \/>\n3) Non appena l'RP riceve un messaggio dal router BSR, invia immediatamente un messaggio unicast all'indirizzo del router BSR:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSuccessivamente, il BSR, ricevuta l'informazione sull'RP, la diffonder\u00e0 in multicast all'indirizzo 224.0.0.13, che ascoltano tutti i router PIM. Pertanto, non esiste un comando equivalente <i>ip pim autorp listener<\/i> per i normali router nel BSR.<br \/>\n<b>Anycast RP con il Protocollo di Scoperta della Multicast Source (MSDP).<\/b><br \/>\nAuto-RP e BSR ci consentono di distribuire il carico su RP nel seguente modo: ogni gruppo multicast ha solo un RP attivo. Non \u00e8 possibile distribuire il carico per un gruppo multicast su pi\u00f9 RP. MSDP lo fa fornendo agli router RP lo stesso indirizzo IP con maschera 255.255.255.255. MSDP acquisisce informazioni tramite uno dei seguenti metodi: statico, Auto-RP o BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNell'immagine abbiamo la configurazione di Auto-RP con MSDP. Entrambi gli RP sono configurati con l'indirizzo IP 172.16.1.1\/32 sull'interfaccia Loopback 1 e viene utilizzato per tutti i gruppi. Durante il RP-Announce, entrambi gli router comunicano di se stessi, facendo riferimento a questo indirizzo. L'agente di mapping Auto-RP, ricevuta l'informazione, invia RP-Discovery sul RP con indirizzo 172.16.1.1\/32. Per la rete 172.16.1.1\/32, informiamo gli router tramite IGP e, di conseguenza. In questo modo, i router PIM richiedono o registrano flussi dall'RP che \u00e8 specificato come next-hop nella rotta verso la rete 172.16.1.1\/32. Il protocollo MSDP \u00e8 progettato per gli RP stessi, per scambiarsi messaggi con informazioni sui multicast.<br \/>\nConsideriamo la seguente topologia:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Principi di funzionamento del protocollo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 trasmette traffico all'indirizzo 238.38.38.38 e al momento solo RP-R1 ne \u00e8 a conoscenza. Ecco perch\u00e9 Switch7 e Switch8 hanno richiesto questo gruppo. I router R5 e R4 invieranno un PIM Join a R1 e R3, rispettivamente. Perch\u00e9? Il percorso verso 13.13.13.13 su R5 far\u00e0 riferimento a R1 secondo la metrica IGP, proprio come R4.<br \/>\nRP-R1 \u00e8 a conoscenza del flusso e inizier\u00e0 a trasmetterlo verso R5, mentre R4 non ne sa nulla, poich\u00e9 R1 non lo invier\u00e0 senza motivo. Pertanto, \u00e8 necessario configurare MSDP. Configurino su R1 e R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 su R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 su R3<\/p><\/blockquote>\n<p>\nStabiliranno una sessione tra di loro e, al ricevimento di un qualsiasi flusso, informeranno il proprio RP vicino.<br \/>\nRP-R1, appena riceve il flusso da Switch6, invier\u00e0 immediatamente un messaggio MSDP Source-Active via unicast, contenente informazioni del tipo (S, G) \u2014 informazioni sulla sorgente e sulla destinazione del multicast. Ora, quando RP-R3 sapr\u00e0 che esiste una sorgente come Switch6, invier\u00e0 un PIM Join verso Switch6 in risposta a una richiesta da parte di R4 per questo flusso, seguendo la tabella di routing. Di conseguenza, R1, ricevendo tale PIM Join, inizier\u00e0 a inviare traffico verso RP-R3.<br \/>\nMSDP opera su TCP, i peer si inviano messaggi keepalive per controllare la vitalit\u00e0. Il timer \u00e8 di 60 secondi.<br \/>\nRimane incerta la funzione di separazione dei peer MSDP in diversi domini, poich\u00e9 nei messaggi Keepalive e SA non si indica a quale dominio appartengano. Inoltre, in questa topologia \u00e8 stata testata una configurazione con indicazione di vari domini, senza differenze nel funzionamento. <br \/>\nSe qualcuno pu\u00f2 fare chiarezza, sar\u00f2 felice di leggere nei commenti.<br \/>\n<br \/>Fonte: <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.0.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\/it\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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 di funzionamento del protocollo PIM | ProHoster","description":"Il protocollo PIM \u00e8 un insieme di protocolli per la trasmissione di multicast in rete tra router. Le relazioni di vicinato sono costruite in modo analogo a quelle dei protocolli di routing dinamici.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}