Il protocollo PIM è 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 è pari a 3,5 volte il Hello Timer, ossia 105 secondi per impostazione predefinita.
PIM utilizza due modalità di funzionamento principali: Dense e Sparse. Iniziamo con la modalità Dense.
Alberi di distribuzione basati su sorgente.
La modalità Dense è 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 è una regola utilizzata per verificare la sorgente del multicast con la tabella di routing unicast. È 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.
R3, dal messaggio multicast, identificherà la fonte del multicast (Source IP) e controllerà due flussi da R1 e R2 attraverso la sua tabella unicast. Il flusso dall'interfaccia indicata nella tabella (R1 verso R3) sarà inoltrato, mentre il flusso da R2 sarà scartato, poiché per raggiungere la fonte multicast è necessario inviare pacchetti tramite S0/1.
Cosa succede se hai due percorsi equivalenti con la stessa metrica? In questo caso, il router sceglierà in base al next-hop di questi percorsi. Chi ha l'indirizzo IP più alto avrà la precedenza. Se è necessario modificare questo comportamento, è possibile utilizzare ECMP. Maggiori dettagli. .
Dopo aver verificato la regola RPF, il router invia il pacchetto multicast a tutti i suoi vicini PIM, ad eccezione di quello da cui è 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 — source-based distribution tree, shortest-path tree (SPT), source tree. Tre nomi diversi, scegli quello che preferisci.
Come 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 è stato inventato il meccanismo Prune.
Messaggio Prune.
Ad esempio, R2 continuerà a inviare multicast a R3, anche se R3, seguendo la regola RPF, lo scarta. Perché sovraccaricare il canale? R3 invia un messaggio PIM Prune e R2, al ricevimento di questo messaggio, rimuoverà l'interfaccia S0/1 dalla lista (outgoing interface list) per questo flusso, la lista delle interfacce da cui inviare questo traffico.
Di seguito è fornita una definizione più formale di un messaggio PIM Prune:
Il messaggio PIM Prune è inviato da un router a un secondo router per far sì che il secondo router rimuova il link su cui viene ricevuto il Prune da un particolare (S,G) SPT.
Dopo il ricevimento del messaggio Prune, R2 imposta il timer Prune a 3 minuti. Dopo tre minuti inizierà a inviare nuovamente il traffico, finché non riceve un altro messaggio Prune. Questo vale per PIMv1.
In PIMv2 è 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à un messaggio di State Refresh, che reimposterà il timer Prune di 3 minuti su R2 per questo gruppo.
Motivi per l'invio del messaggio Prune:
- Quando un pacchetto multicast non supera il controllo RPF.
- 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).
Messaggio Graft.
Immaginiamo 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é il Prune Timer su R2 non scade. 3 minuti sono tanti, per non aspettare, è necessario inviare un messaggio che toglie immediatamente l'interfaccia S0/1 su R2 dallo stato pruned. Questo messaggio sarà il messaggio Graft. Dopo aver ricevuto il messaggio Graft, R2 invierà in risposta un Graft-ACK.
Prune Override.
Esaminiamo 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à della situazione. Prima che R1 smetta di trasmettere, imposta un timer di 3 secondi e smetterà di trasmettere tra 3 secondi. 3 secondi: questo è il tempo che R3 ha per non perdere il suo multicast. Pertanto, R3 invia il messaggio Pim Join per questo gruppo il più rapidamente possibile e R1 non pensa più a smettere di trasmettere. Di seguito sono riportati i messaggi Join.
Messaggio di Asserzione.
Immagina 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à 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'è 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 — 10.1.1.10. Il vincitore viene determinato in questo modo:
- Quello con l'AD più basso.
- Se l'AD è uguale, vince chi ha la metrica più bassa.
- Se c'è ancora parità, vince chi ha l'IP più alto nella rete in cui trasmettono questo multicast.
Il 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 è stato mostrato un messaggio PIM Hello, dove è possibile notare il campo DR. Vince chi ha l'IP più alto su questo link.
Tabella utile:
MROUTE Table.
Dopo 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.
Ad 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):
Questa voce indica che è stata ricevuta una richiesta di traffico dall'indirizzo 238.38.38.38. Il flag DC indica che il multicast opererà in modalità Dense e C indica che il ricevente è direttamente connesso al router, ovvero il router ha ricevuto un IGMP Membership Report e un PIM Join.
Se c'è una voce di tipo (S,G), significa che abbiamo un flusso multicast:
Nel campo S — 192.168.1.11, abbiamo registrato l'indirizzo IP della fonte multicast, che sarà verificato dalla regola RPF. In caso di problemi, la prima cosa da controllare è 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à indirizzato il multicast. Se è vuota, significa che non ci sono state richieste per questo traffico al router. Ulteriori informazioni su tutti i flag sono disponibili. .
PIM Sparse-mode.
La strategia Sparse-mode è opposta alla Dense-mode. Quando la Sparse-mode riceve traffico multicast, invierà 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.
Elementi simili in SM e DM:
- Le relazioni di vicinato vengono costruite come in PIM DM.
- La regola RPF è attiva.
- La scelta del DR è simile.
- Il meccanismo Prune Overrides e i messaggi Assert sono analoghi.
Per monitorare a chi, dove e quale traffico multicast è necessario nella rete, è necessario un centro informativo generale. Questo centro sarà 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.
Quando il RP riceve il traffico multicast, lo inoltra ai router che lo hanno richiesto in precedenza.
Immaginiamo 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 è il RP? In questo caso, è configurato staticamente, ma parleremo della configurazione dinamica del RP più avanti.
ip pim rp-address 3.3.3.3
RP verificherà se ci fosse stata qualche informazione da parte di qualcuno che desiderava ricevere questo traffico. Supponiamo di no. In tal caso, RP invierà a R1 un messaggio PIM Register-Stop, che significa che nessuno è interessato a questo multicast, la registrazione è stata rifiutata. R1 non invierà multicast. Tuttavia, la fonte host del multicast continuerà a trasmetterlo, quindi R1, dopo aver ricevuto Register-Stop, avvierà un timer di soppressione della registrazione, impostato a 60 secondi. Cinque secondi prima della scadenza di questo timer, R1 invierà un messaggio Register vuoto con il bit Null-Register (cioè senza pacchetto multicast incapsulato) verso RP. RP agirà nel seguente modo:
- Se non ci sono destinatari, risponderà con un messaggio Register-Stop.
- Se compaiono destinatari, non risponderà in alcun modo. R1, non ricevendo rifiuto alla sua registrazione entro 5 secondi, si rallegrerà e invierà un messaggio Register con multicast incapsulato a RP.
Abbiamo capito come il multicast raggiunge il RP, ora cerchiamo di rispondere alla domanda su come il RP porta il traffico ai destinatari. Qui è necessario introdurre un nuovo concetto: il root-path tree (RPT). L'RPT è 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ì fa ogni router sottostante. La regola generale è la seguente:
- 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.
- Un ramo viene aggiunto anche quando un router PIM-SM riceve un IGMP Membership Report da un host a cui è direttamente connesso.
Immaginiamo 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ì si ottiene la registrazione del ricevitore multicast. Viene costruito un albero con la radice R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Dopo di ciò, verrà inviato un PIM Join a R1 e R1 inizierà a inviare traffico multicast. È importante notare che, se un host ha richiesto traffico prima che iniziasse la trasmissione multicast, l'RP non invierà un PIM Join e in generale non invierà nulla verso R1.
Se durante l'invio del multicast, l'host smette di volerlo ricevere, non appena l'RP riceve un PIM Prune sull'interfaccia Gi0/0, invierà 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 è stato ricevuto il PIM Register.
Come 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:
E si avvia un timer, il quale deve essere costantemente resettato da R5 inviando messaggi PIM Join, altrimenti R4 lo escluderà dall'elenco in uscita. R5 invierà messaggi PIM Join ogni 60 secondi.
Commutazione dell'albero del percorso più breve.
Aggiungeremo un'interfaccia tra R1 e R5 e osserveremo come fluirà il traffico in questa topologia.
Supponiamo 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.
Per prima cosa, la nostra tabella di instradamento multicast si è ristrutturata su R5 e ora la rete 192.168.1.0/24 è raggiungibile attraverso l'interfaccia R5 Gi0/2. Ora R5, ricevendo multicast sull'interfaccia Gi0/1, comprende che la regola RPF non è soddisfatta e sarebbe più logico ricevere multicast su Gi0/2. Deve disconnettersi da RPT e costruire un albero più 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 — 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à a inviare PIM Prune a RP, poiché R1 continua a inviare PIM Register a RP ogni minuto. RP, finché non ci saranno nuovi richiedenti di questo traffico, risponderà rifiutando. R5 informa RP che continua a ricevere multicast tramite SPT.
Ricerca dinamica di RP.
Auto-RP.
Questa tecnologia è proprietaria di Cisco e non è molto popolare, ma è ancora attiva. Il funzionamento di Auto-RP si basa su due fasi principali:
1) L'RP invia messaggi RP-Announce all'indirizzo riservato — 224.0.1.39, annunciando se stesso come RP per tutti o per gruppi specifici. Questo messaggio viene inviato ogni minuto.
2) È 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ò 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.
Approfondiamo il processo:
Configuriamo R3 come RP:
ip pim send-rp-announce loopback 0 scope 10
R2 come mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
E sugli altri aspetti aspetteremo l'RP tramite Auto-RP:
ip pim autorp listener
Non appena configureremo R3, inizierà a inviare RP-Announce:
E R2, dopo essere stato configurato come mapping agent, inizierà ad attendere i messaggi RP-Announce. Solo quando troverà almeno un RP, inizierà a inviare RP-Discovery:
Quindi, non appena i normali router (PIM RP Listener) ricevono questo messaggio, sapranno dove cercare il RP.
Uno dei problemi principali di Auto-RP è che, per ricevere messaggi RP-Announce e RP-Discovery, è necessario inviare PIM Join agli indirizzi 224.0.1.39-40, e per farlo, bisogna sapere dove si trova il RP. È il classico problema dell'uovo e della gallina. Per risolvere questo problema, è stata ideata la modalità PIM Sparse-Dense. Se il router non conosce il RP, opera in modalità Dense-mode; se lo conosce, in modalità Sparse-mode. Quando le interfacce dei normali router sono configurate in PIM Sparse-mode con il comando ip pim autorp listener, il router opererà in modalità Dense-mode solo per il multicast relativo direttamente al protocollo Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Questa 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:
1) Non appena configuriamo R3 come candidato a essere RP, con il comando:
ip pim rp-candidate loopback 0
R3 non farà nulla. Per iniziare a inviare messaggi speciali, deve prima trovare un agent di mapping. Passiamo quindi al secondo passaggio.
2) Configuriamo R2 come agent di mapping:
ip pim bsr-candidate loopback 0
R2 inizia a inviare messaggi PIM Bootstrap in cui si propone come agent di mapping:
Questo 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'è il problema dell'uovo e della gallina, come avveniva con Auto-RP.
3) Non appena l'RP riceve un messaggio dal router BSR, invia immediatamente un messaggio unicast all'indirizzo del router BSR:
Successivamente, il BSR, ricevuta l'informazione sull'RP, la diffonderà in multicast all'indirizzo 224.0.0.13, che ascoltano tutti i router PIM. Pertanto, non esiste un comando equivalente ip pim autorp listener per i normali router nel BSR.
Anycast RP con il Protocollo di Scoperta della Multicast Source (MSDP).
Auto-RP e BSR ci consentono di distribuire il carico su RP nel seguente modo: ogni gruppo multicast ha solo un RP attivo. Non è possibile distribuire il carico per un gruppo multicast su più 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.
Nell'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 è specificato come next-hop nella rotta verso la rete 172.16.1.1/32. Il protocollo MSDP è progettato per gli RP stessi, per scambiarsi messaggi con informazioni sui multicast.
Consideriamo la seguente topologia:
Switch6 trasmette traffico all'indirizzo 238.38.38.38 e al momento solo RP-R1 ne è a conoscenza. Ecco perché Switch7 e Switch8 hanno richiesto questo gruppo. I router R5 e R4 invieranno un PIM Join a R1 e R3, rispettivamente. Perché? Il percorso verso 13.13.13.13 su R5 farà riferimento a R1 secondo la metrica IGP, proprio come R4.
RP-R1 è a conoscenza del flusso e inizierà a trasmetterlo verso R5, mentre R4 non ne sa nulla, poiché R1 non lo invierà senza motivo. Pertanto, è necessario configurare MSDP. Configurino su R1 e R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 su R1
ip msdp peer 1.1.1.1 connect-source Loopback3 su R3
Stabiliranno una sessione tra di loro e, al ricevimento di un qualsiasi flusso, informeranno il proprio RP vicino.
RP-R1, appena riceve il flusso da Switch6, invierà immediatamente un messaggio MSDP Source-Active via unicast, contenente informazioni del tipo (S, G) — informazioni sulla sorgente e sulla destinazione del multicast. Ora, quando RP-R3 saprà che esiste una sorgente come Switch6, invierà 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à a inviare traffico verso RP-R3.
MSDP opera su TCP, i peer si inviano messaggi keepalive per controllare la vitalità. Il timer è di 60 secondi.
Rimane incerta la funzione di separazione dei peer MSDP in diversi domini, poiché nei messaggi Keepalive e SA non si indica a quale dominio appartengano. Inoltre, in questa topologia è stata testata una configurazione con indicazione di vari domini, senza differenze nel funzionamento.
Se qualcuno può fare chiarezza, sarò felice di leggere nei commenti.
Fonte: habr.com
