{"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 del multicast nelle reti tra router. Le relazioni di vicinato si costruiscono in modo simile a quelle dei protocolli di routing dinamici. PIMv2 invia messaggi Hello ogni 30 secondi all'indirizzo multicast riservato 224.0.0.13 (All-PIM-Routers). Il messaggio contiene Hold Timers \u2014 solitamente pari a 3.5*Hello Timer, ovvero 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 principali di funzionamento \u2014 Dense e Sparse. Iniziamo con la modalit\u00e0 Dense. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Alberi di distribuzione basati sulla sorgente.<\/b><br \/>\nLa modalit\u00e0 dense \u00e8 consigliata in caso di un gran numero di client appartenenti a diversi gruppi multicast. Quando un router riceve traffico multicast, prima di tutto verifica la regola RPF. RPF \u00e8 una regola utilizzata per confrontare la sorgente del multicast con la tabella di routing unicast. \u00c8 necessario che il traffico arrivi all'interfaccia dietro cui si trova quell'host secondo la tabella di routing unicast. Questo meccanismo risolve il problema della creazione di loop nella 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, dai messaggi multicast, scopre la sorgente del multicast (Source IP) e controlla i due flussi da R1 e R2 nella sua tabella di routing unicast. Il flusso dall'interfaccia indicata dalla tabella (da R1 a R3) verr\u00e0 trasmesso ulteriormente, mentre il flusso da R2 sar\u00e0 scartato, poich\u00e9 per arrivare alla sorgente del multicast, \u00e8 necessario inviare pacchetti tramite S0\/1.<br \/>\nCosa succede se avete 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 vince. Se \u00e8 necessario modificare questo comportamento, \u00e8 possibile utilizzare l'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, eccetto a quello da cui ha ricevuto il pacchetto. Gli altri router PIM ripetono questo processo. Il percorso seguito dal pacchetto multicast dalla sorgente ai destinatari finali forma un albero, chiamato \u2014 albero di distribuzione basato sulla sorgente, albero del percorso pi\u00f9 breve (SPT), albero della sorgente. Tre nomi diversi, scegliete quello che preferite.<br \/>\nCome risolvere la questione di un certo flusso multicast che non ha un destinatario su alcuni router e viene inviato dal router superiore? A questo scopo \u00e8 stato inventato il meccanismo Prune. <br \/>\n<b>Messaggio di Prune.<\/b><br \/>\nAd esempio, R2 continuer\u00e0 a inviare R3 multicast, anche se R3 scarta il pacchetto secondo la regola RPF. Perch\u00e9 appesantire la rete? R3 invia un messaggio PIM Prune e R2, alla ricezione di questo messaggio, rimuover\u00e0 l'interfaccia S0\/1 dall'elenco delle interfacce in uscita per questo flusso, l'elenco delle interfacce da cui inviare questo traffico. <\/p>\n<blockquote><p>La seguente \u00e8 una definizione pi\u00f9 formale di un messaggio PIM Prune:<br \/>\nIl messaggio PIM Prune viene inviato da un router a un secondo router per far s\u00ec che il secondo router rimuova il collegamento su cui il Prune \u00e8 ricevuto da un particolare SPT (S,G).<\/p><\/blockquote>\n<p>\nDopo aver ricevuto il messaggio Prune, R2 imposta un timer Prune di 3 minuti. Dopo tre minuti, ricomincer\u00e0 a inviare traffico finch\u00e9 non ricever\u00e0 un altro messaggio Prune. Questo \u00e8 in PIMv1.<br \/>\nIn PIMv2 \u00e8 stato aggiunto un timer di State Refresh (di default 60 secondi). Non appena \u00e8 stato inviato un messaggio Prune da R3, inizia questo timer su R3. Una volta scaduto questo timer, R3 invier\u00e0 un messaggio di State Refresh, che resetter\u00e0 il timer Prune di 3 minuti su R2 per questo gruppo. <br \/>\nMotivi per l'invio di un messaggio Prune:<\/p>\n<ul>\n<li> Quando il pacchetto multicast non supera il controllo RPF.<\/li>\n<li> Quando non ci sono clienti connessi localmente che hanno richiesto un gruppo multicast (IGMP Join) e non ci sono vicini PIM a cui inviare traffico multicast (Interfaccia non prune).<\/li>\n<\/ul>\n<p>\n<b>Messaggio Graft.<\/b><br \/>\nImmaginiamo che R3 non volesse il traffico da R2, abbia inviato un Prune e ricevuto multicast da R1. Ma improvvisamente, il collegamento tra R1 e R3 \u00e8 caduto e R3 \u00e8 rimasto senza multicast. Si possono attendere 3 minuti, finch\u00e9 il timer Prune su R2 non scade. Aspettare 3 minuti \u00e8 lungo, per non aspettare, \u00e8 necessario inviare un messaggio che porti immediatamente questa interfaccia S0\/1 su R2 fuori dallo stato pruned. Un tale 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 nel segmento con due router. R3 riceve e trasmette il traffico, R2 riceve ma non ha nessuno a cui trasmettere. Invia un messaggio Prune a R1 in questo segmento. R1 deve rimuovere Fa0\/0 dalla lista e smettere di trasmettere in questo segmento, ma cosa succeder\u00e0 a R3? E R3 si trova nello stesso segmento, ha ricevuto questo messaggio Prune e ha compreso tutta la tragicit\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 ha R3 per non perdere il suo multicast. Pertanto, R3 invia il prima possibile un messaggio Pim Join per questo gruppo e R1 non pensa pi\u00f9 di smettere di trasmettere. Di seguito sono riportati ulteriori dettagli sui messaggi di Join.<br \/>\n<b>Assert Message.<\/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 \/>\nImmaginiamo una situazione in cui due router trasmettono contemporaneamente nella stessa rete. Ricevono lo stesso flusso da una sorgente e entrambi lo trasmettono in una rete attraverso l'interfaccia e0. \u00c8 quindi necessario determinare chi sar\u00e0 l'unico trasmettitore per questa rete. A tale scopo si utilizzano i messaggi Assert. Quando R2 e R3 rilevano la duplicazione del traffico multicast, cio\u00e8 ricevono multicast che loro stessi trasmettono, i router capiscono che c'\u00e8 qualcosa che non va. In questo caso, i router inviano messaggi Assert, che includono la Administrative Distance e la metrica del percorso attraverso cui si raggiunge la sorgente del multicast: 10.1.1.10. Il vincitore viene determinato in questo modo:<\/p>\n<ol>\n<li>Chi ha un AD pi\u00f9 basso.<\/li>\n<li>Se l'AD \u00e8 uguale, chi ha una metrica pi\u00f9 bassa.<\/li>\n<li>Se anche in questo caso c'\u00e8 parit\u00e0, chi ha un IP pi\u00f9 alto nella rete in cui trasmettono questo multicast.<\/li>\n<\/ol>\n<p>\nIl router vincitore di questa votazione diventa il Designated Router. Anche per la scelta del DR si utilizzano 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 gli indirizzi IP pi\u00f9 alti 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 aver esaminato l'operato del protocollo PIM, dobbiamo capire come lavorare con la tabella di routing multicast. Nella tabella mroute viene memorizzata l'informazione su quali flussi sono stati richiesti dai clienti e quali flussi provengono dai server multicast. <br \/>\nAd esempio, quando si riceve un IGMP Membership Report o un PIM Join su una certa interfaccia, viene aggiunta una voce di tipo (*, G) nella tabella di routing:<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 funzioner\u00e0 in modalit\u00e0 Dense mode e S significa che il ricevente \u00e8 direttamente connesso al router, cio\u00e8 il router ha ricevuto un IGMP Membership Report e un PIM Join.<br \/>\nSe c'\u00e8 un record 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 specificato l'indirizzo IP della sorgente multicast, che sar\u00e0 controllato dalla regola RPF. In caso di problemi, prima di tutto \u00e8 necessario controllare la tabella unicast per la rotta verso la sorgente. Nel campo Interfaccia in Entrata si indica l'interfaccia su cui arriva il multicast. Nella tabella di routing unicast, la rotta verso la sorgente deve fare riferimento all'interfaccia indicata qui. Nell'Interfaccia in Uscita si indica dove sar\u00e0 reindirizzato il multicast. Se \u00e8 vuota, significa che al router non sono arrivate richieste per questo traffico. Maggiori informazioni su tutti i flag possono essere trovate <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 quelle interfacce dove ci sono state richieste per quel flusso, ad esempio messaggi Pim Join o IGMP Report con richiesta per quel traffico.<br \/>\nElementi simili in SM e DM:<\/p>\n<ul>\n<li> Le relazioni di vicinato vengono costruite allo stesso modo che in PIM DM.<\/li>\n<li> Funziona la regola RPF.<\/li>\n<li> La selezione del DR \u00e8 simile.<\/li>\n<li> I meccanismi Prune Overrides e i messaggi Assert sono analoghi.<\/li>\n<\/ul>\n<p>\nPer controllare a chi, dove e quale traffico multicast \u00e8 necessario nella rete, \u00e8 necessario un centro informativo comune. Tale centro sar\u00e0 il Rendezvous Point (RP). Tutti coloro che desiderano traffico multicast o chi ha iniziato a ricevere traffico multicast dalla sorgente inviano a RP.<br \/>\nQuando RP riceve traffico multicast, lo invia ai router che in precedenza avevano richiesto quel traffico. <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 RP \u00e8 R3. Non appena R1 riceve traffico da S1, incapsula questo pacchetto multicast in un messaggio PIM Register unicast e lo invia a RP. Come fa a sapere chi \u00e8 RP? In questo caso, \u00e8 impostato staticamente, mentre parleremo pi\u00f9 tardi della configurazione dinamica di RP. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP verificher\u00e0 se ci sono informazioni da qualcuno che desidererebbe ricevere questo traffico? Supponiamo di no. Allora RP invier\u00e0 a R1 un messaggio PIM Register-Stop, il che significa che nessuno ha bisogno di questo multicast, la registrazione \u00e8 stata rifiutata. R1 non invier\u00e0 multicast. Ma l'host sorgente del multicast lo invier\u00e0 comunque, quindi dopo aver ricevuto Register-Stop, R1 avvier\u00e0 un timer di soppressione della registrazione di 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 come segue:<\/p>\n<ul>\n<li> Se i destinatari non ci sono stati, non ci saranno nemmeno ora; quindi risponder\u00e0 con un messaggio Register-Stop.<\/li>\n<li> Se ci sono destinatari, non risponder\u00e0 in alcun modo. R1, non ricevendo un rifiuto della sua registrazione entro 5 secondi, si rallegrer\u00e0 e invier\u00e0 un messaggio Register con il multicast incapsulato a RP.<\/li>\n<\/ul>\n<p>\nAbbiamo capito come il multicast arriva a RP, ora cerchiamo di rispondere alla domanda su come RP porta il traffico ai destinatari. Qui dobbiamo introdurre un nuovo concetto: l'albero del percorso radice (RPT). RPT \u00e8 un albero con radice in RP, che cresce verso i destinatari, ramificandosi su ciascun router PIM-SM. RP lo crea ricevendo messaggi PIM Join e aggiungendo 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 qualsiasi, tranne quella dietro la quale si trova RP, aggiunge un nuovo ramo all'albero.<\/li>\n<li> Un ramo viene anche aggiunto quando un router PIM-SM riceve un IGMP Membership Report da un host direttamente connesso. <\/li>\n<\/ul>\n<p>\nImmaginiamo di avere un cliente multicast sul router R5 per il gruppo 228.8.8.8. Non appena R5 riceve l'IGMP Membership Report dall'host, R5 invia un PIM Join verso RP, mentre 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 RP. Infine, RP (R3) riceve il PIM Join e aggiunge Gi0\/0 all'albero. Cos\u00ec si ottiene la registrazione del destinatario multicast. Si costruisce un albero con 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 di multicast, allora l'RP non invier\u00e0 PIM Join e non invier\u00e0 nulla verso R1.<br \/>\nSe per caso mentre viene inviato il multicast, l'host smette di volerlo ricevere, non appena l'RP riceve PIM Prune sull'interfaccia Gi0\/0, invier\u00e0 immediatamente PIM Register-Stop direttamente a R1 e poi il messaggio PIM Prune attraverso l'interfaccia Gi0\/1. PIM Register-stop viene inviato in unicast all'indirizzo da cui \u00e8 stato ricevuto PIM Register.<br \/>\nCome abbiamo detto prima, non appena il router invia PIM Join a un altro, ad esempio a R5 su 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 viene avviato un timer, il che significa che R5 deve inviare costantemente messaggi PIM Join per mantenere attivo questo timer, altrimenti R4 lo escluder\u00e0 dalla lista di uscita. R5 invier\u00e0 messaggi PIM Join ogni 60 secondi.<br \/>\n<b>Switching dell'albero di percorso pi\u00f9 breve.<\/b><br \/>\nAggiungeremo un'interfaccia tra R1 e R5 e vedremo come fluir\u00e0 il traffico con 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 tabella di routing unicast su R5 si ristrutturer\u00e0 e ora la rete 192.168.1.0\/24 sar\u00e0 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 il multicast su Gi0\/2. Deve disconnettersi dall'RPT e costruire un albero pi\u00f9 corto, chiamato Shortest-Path Tree (SPT). Per questo, invia un PIM Join a R1 tramite Gi0\/2 e R1 inizia a inviare multicast anche attraverso Gi0\/2. Ora R5 deve disiscriversi dall'RPT per non ricevere due copie. A tale scopo, 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. Anche l'RP invia messaggi PIM Prune verso R1, ma non invia messaggi Register-Stop. Un'altra particolarit\u00e0: R5 ora invier\u00e0 costantemente PIM Prune all'RP, poich\u00e9 R1 continua a inviare PIM Register all'RP ogni minuto. Finch\u00e9 non ci saranno nuovi richiedenti di questo traffico, l'RP risponder\u00e0 negativamente a lui. R5 informa l'RP che continua a ricevere multicast tramite SPT.<br \/>\n<b>Ricerca dinamica dell'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 compone di due fasi principali:<br \/>\n1) Il RP invia messaggi RP-Announce all'indirizzo riservato \u2014 224.0.1.39, dichiarando di essere il RP, sia per tutti che per gruppi specifici. Questo messaggio viene inviato ogni minuto.<br \/>\n2) \u00c8 necessario un agente di mappatura RP, che invier\u00e0 messaggi RP-Discovery specificando a quali gruppi quale RP deve ascoltare. Proprio da questo messaggio, i normali router PIM determineranno il proprio RP. L'agente di mappatura pu\u00f2 essere sia il router RP stesso, che un router PIM separato. RP-Discovery viene inviato all'indirizzo 224.0.1.40 con un timer di un minuto.<br \/>\nEsaminiamo il processo pi\u00f9 nel dettaglio:<br \/>\nConfiguriamo R3 come RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 come agente di mappatura:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nE su tutti gli altri aspetti aspetteremo il RP tramite Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nNon appena configuriamo 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 la configurazione come agente di mappatura, inizier\u00e0 ad attendere i messaggi RP-Announce. Solo quando ne trova almeno uno, 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 \/>\nCos\u00ec, una volta che i normali router (PIM RP Listener) ricevono questo messaggio, sapranno dove cercare il RP.<br \/>\nUno dei principali problemi di Auto-RP \u00e8 che, per ricevere i messaggi RP-Announce e RP-Discovery, \u00e8 necessario inviare un PIM Join agli indirizzi 224.0.1.39-40, e per farlo, bisogna sapere dove si trova il RP. Il classico problema del pollo e delle uova. Per risolvere questo problema \u00e8 stata inventata la modalit\u00e0 PIM Sparse-Dense. Se il router non conosce il RP, funziona in modalit\u00e0 Dense-mode; se lo conosce, in modalit\u00e0 Sparse-mode. Quando sulle interfacce dei normali router \u00e8 configurato PIM Sparse-mode e il comando ip pim autorp listener, il router funzioner\u00e0 in modalit\u00e0 Dense-mode solo per il multicast direttamente del protocollo Auto-RP (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nQuesta funzione opera in modo simile a Auto-RP. Ogni RP invia un messaggio all'agente di mappatura, che raccoglie informazioni di mappatura e poi 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 l'agente di mappatura. Quindi, passiamo al secondo passo.<br \/>\n2) Configuriamo R2 come agente di mappatura:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 inizia a inviare messaggi PIM Bootstrap, indicando se stesso come mapping agent:<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 messaggi. Viene inviato in tutte le direzioni e quindi non ci sono problemi di gallina e uovo, come avveniva con Auto-RP.<br \/>\n3) Non appena il 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 \/>\nDopo di ci\u00f2, il BSR, ricevuta l'informazione sul RP, la diffonde 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 in BSR.<br \/>\n<b>Anycast RP con il Protocollo di Scoperta della Sorgente Multicast (MSDP).<\/b><br \/>\nAuto-RP e BSR ci permettono di distribuire il carico sui 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 fa questo fornendo agli RP indirizzi IP identici ai router con una maschera 255.255.255.255. MSDP ottiene 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 una configurazione Auto-RP con MSDP. Entrambi gli RP sono configurati con l'indirizzo IP 172.16.1.1\/32 sull'interfaccia Loopback 1 e sono utilizzati per tutti i gruppi. Durante il RP-Announce entrambi i router si segnalano, facendo riferimento a questo indirizzo. L'agente di mapping Auto-RP, ricevuta l'informazione, diffonde il RP-Discovery del RP con l'indirizzo 172.16.1.1\/32. Per la rete 172.16.1.1\/32, ai router forniamo informazioni tramite IGP, e di conseguenza. In questo modo, i router PIM richiedono o registrano i flussi da quel RP, che \u00e8 indicato come next-hop nella rotta verso la rete 172.16.1.1\/32. Il protocollo MSDP serve dunque per gli stessi RP, per scambiarsi 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 finora solo RP-R1 ne \u00e8 a conoscenza. Gli Switch7 e Switch8 hanno richiesto questo gruppo. I router R5 e R4 invieranno PIM Join a R1 e R3, rispettivamente. Perch\u00e9? La rotta verso 13.13.13.13 su R5 far\u00e0 riferimento a R1 in base alla metrica IGP, come anche 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 MSDP. Lo configuriamo 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>\nEssi stabiliranno una sessione tra di loro e, al ricevimento di un qualsiasi flusso, informeranno il loro RP vicino.<br \/>\nRP-R1, non appena riceve il flusso da Switch6, invier\u00e0 immediatamente un messaggio MSDP Source-Active in unicast, contenente informazioni di tipo (S,G) \u2014 informazioni sulla fonte e sul destinatario del multicast. Ora, quando RP-R3 sapr\u00e0 che esiste una fonte come Switch6, alla ricezione di una richiesta da parte di R4 per questo flusso, invier\u00e0 una PIM Join verso Switch6, facendosi guidare dalla tabella di routing. Di conseguenza, R1, ricevuta tale PIM Join, inizier\u00e0 a inviare traffico verso RP-R3.<br \/>\nMSDP funziona su TCP, RP si inviano messaggi keepalive per verificare la vitalit\u00e0. Il timer \u00e8 impostato su 60 secondi.<br \/>\nRimane poco chiara la funzione di separation dei peer MSDP in diversi domini, poich\u00e9 nei messaggi Keepalive e SA non viene specificata l\u2019appartenenza a un dominio. Inoltre, in questa topologia \u00e8 stata testata una configurazione con diverse specifiche di dominio \u2014 non c'era differenza nel funzionamento. <br \/>\nSe qualcuno pu\u00f2 fare chiarezza, sarei 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.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"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 nelle reti tra i router. Le relazioni di vicinanza vengono stabilite in modo analogo a quanto avviene con i protocolli di routing dinamico.","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}]}}