Il protocollo PIM è 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 — solitamente pari a 3.5*Hello Timer, ovvero 105 secondi per impostazione predefinita.
PIM utilizza due modalità principali di funzionamento — Dense e Sparse. Iniziamo con la modalità Dense.
Alberi di distribuzione basati sulla sorgente.
La modalità dense è 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 è una regola utilizzata per confrontare la sorgente del multicast con la tabella di routing unicast. È 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.
R3, 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à trasmesso ulteriormente, mentre il flusso da R2 sarà scartato, poiché per arrivare alla sorgente del multicast, è necessario inviare pacchetti tramite S0/1.
Cosa succede se avete 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 vince. Se è necessario modificare questo comportamento, è possibile utilizzare l'ECMP. Maggiori dettagli. .
Dopo 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 — albero di distribuzione basato sulla sorgente, albero del percorso più breve (SPT), albero della sorgente. Tre nomi diversi, scegliete quello che preferite.
Come 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 è stato inventato il meccanismo Prune.
Messaggio di Prune.
Ad esempio, R2 continuerà a inviare R3 multicast, anche se R3 scarta il pacchetto secondo la regola RPF. Perché appesantire la rete? R3 invia un messaggio PIM Prune e R2, alla ricezione di questo messaggio, rimuoverà l'interfaccia S0/1 dall'elenco delle interfacce in uscita per questo flusso, l'elenco delle interfacce da cui inviare questo traffico.
La seguente è una definizione più formale di un messaggio PIM Prune:
Il messaggio PIM Prune viene inviato da un router a un secondo router per far sì che il secondo router rimuova il collegamento su cui il Prune è ricevuto da un particolare SPT (S,G).
Dopo aver ricevuto il messaggio Prune, R2 imposta un timer Prune di 3 minuti. Dopo tre minuti, ricomincerà a inviare traffico finché non riceverà un altro messaggio Prune. Questo è in PIMv1.
In PIMv2 è stato aggiunto un timer di State Refresh (di default 60 secondi). Non appena è stato inviato un messaggio Prune da R3, inizia questo timer su R3. Una volta scaduto questo timer, R3 invierà un messaggio di State Refresh, che resetterà il timer Prune di 3 minuti su R2 per questo gruppo.
Motivi per l'invio di un messaggio Prune:
- Quando il pacchetto multicast non supera il controllo RPF.
- 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).
Messaggio Graft.
Immaginiamo 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 è caduto e R3 è rimasto senza multicast. Si possono attendere 3 minuti, finché il timer Prune su R2 non scade. Aspettare 3 minuti è lungo, per non aspettare, è necessario inviare un messaggio che porti immediatamente questa interfaccia S0/1 su R2 fuori dallo stato pruned. Un tale 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 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à a R3? E R3 si trova nello stesso segmento, ha ricevuto questo messaggio Prune e ha compreso tutta la tragicità 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 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ù di smettere di trasmettere. Di seguito sono riportati ulteriori dettagli sui messaggi di Join.
Assert Message.
Immaginiamo 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. È quindi necessario determinare chi sarà 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è ricevono multicast che loro stessi trasmettono, i router capiscono che c'è 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:
- Chi ha un AD più basso.
- Se l'AD è uguale, chi ha una metrica più bassa.
- Se anche in questo caso c'è parità, chi ha un IP più alto nella rete in cui trasmettono questo multicast.
Il 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 è stato mostrato un messaggio PIM Hello, dove è possibile notare il campo DR. Vince chi ha gli indirizzi IP più alti su questo link.
Tabella utile:
MROUTE Table.
Dopo 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.
Ad 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:
Questa voce indica che è stata ricevuta una richiesta di traffico dall'indirizzo 238.38.38.38. Il flag DC indica che il multicast funzionerà in modalità Dense mode e S significa che il ricevente è direttamente connesso al router, cioè il router ha ricevuto un IGMP Membership Report e un PIM Join.
Se c'è un record di tipo (S,G), significa che abbiamo un flusso multicast:
Nel campo S — 192.168.1.11, abbiamo specificato l'indirizzo IP della sorgente multicast, che sarà controllato dalla regola RPF. In caso di problemi, prima di tutto è 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à reindirizzato il multicast. Se è vuota, significa che al router non sono arrivate richieste per questo traffico. Maggiori informazioni su tutti i flag possono essere trovate .
PIM Sparse-mode.
La strategia Sparse-mode è opposta alla Dense-mode. Quando la Sparse-mode riceve traffico multicast, invierà 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.
Elementi simili in SM e DM:
- Le relazioni di vicinato vengono costruite allo stesso modo che in PIM DM.
- Funziona la regola RPF.
- La selezione del DR è simile.
- I meccanismi Prune Overrides e i messaggi Assert sono analoghi.
Per controllare a chi, dove e quale traffico multicast è necessario nella rete, è necessario un centro informativo comune. Tale centro sarà il Rendezvous Point (RP). Tutti coloro che desiderano traffico multicast o chi ha iniziato a ricevere traffico multicast dalla sorgente inviano a RP.
Quando RP riceve traffico multicast, lo invia ai router che in precedenza avevano richiesto quel traffico.
Immaginiamo una topologia in cui RP è 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 è RP? In questo caso, è impostato staticamente, mentre parleremo più tardi della configurazione dinamica di RP.
ip pim rp-address 3.3.3.3
RP verificherà se ci sono informazioni da qualcuno che desidererebbe ricevere questo traffico? Supponiamo di no. Allora RP invierà a R1 un messaggio PIM Register-Stop, il che significa che nessuno ha bisogno di questo multicast, la registrazione è stata rifiutata. R1 non invierà multicast. Ma l'host sorgente del multicast lo invierà comunque, quindi dopo aver ricevuto Register-Stop, R1 avvierà un timer di soppressione della registrazione di 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à come segue:
- Se i destinatari non ci sono stati, non ci saranno nemmeno ora; quindi risponderà con un messaggio Register-Stop.
- Se ci sono destinatari, non risponderà in alcun modo. R1, non ricevendo un rifiuto della sua registrazione entro 5 secondi, si rallegrerà e invierà un messaggio Register con il multicast incapsulato a RP.
Abbiamo 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 è 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ì fa ogni router sottostante. La regola generale è la seguente:
- 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.
- Un ramo viene anche aggiunto quando un router PIM-SM riceve un IGMP Membership Report da un host direttamente connesso.
Immaginiamo 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ì si ottiene la registrazione del destinatario multicast. Si costruisce un albero con 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 di multicast, allora l'RP non invierà PIM Join e non invierà nulla verso R1.
Se 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à 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 è stato ricevuto PIM Register.
Come 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:
E viene avviato un timer, il che significa che R5 deve inviare costantemente messaggi PIM Join per mantenere attivo questo timer, altrimenti R4 lo escluderà dalla lista di uscita. R5 invierà messaggi PIM Join ogni 60 secondi.
Switching dell'albero di percorso più breve.
Aggiungeremo un'interfaccia tra R1 e R5 e vedremo come fluirà il traffico con 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 tabella di routing unicast su R5 si ristrutturerà e ora la rete 192.168.1.0/24 sarà 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 il multicast su Gi0/2. Deve disconnettersi dall'RPT e costruire un albero più 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 — 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à: R5 ora invierà costantemente PIM Prune all'RP, poiché R1 continua a inviare PIM Register all'RP ogni minuto. Finché non ci saranno nuovi richiedenti di questo traffico, l'RP risponderà negativamente a lui. R5 informa l'RP che continua a ricevere multicast tramite SPT.
Ricerca dinamica dell'RP.
Auto-RP.
Questa tecnologia è proprietaria di Cisco e non è molto popolare, ma è ancora attiva. Il funzionamento di Auto-RP si compone di due fasi principali:
1) Il RP invia messaggi RP-Announce all'indirizzo riservato — 224.0.1.39, dichiarando di essere il RP, sia per tutti che per gruppi specifici. Questo messaggio viene inviato ogni minuto.
2) È necessario un agente di mappatura RP, che invierà 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ò 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.
Esaminiamo il processo più nel dettaglio:
Configuriamo R3 come RP:
ip pim send-rp-announce loopback 0 scope 10
R2 come agente di mappatura:
ip pim send-rp-discovery loopback 0 scope 10
E su tutti gli altri aspetti aspetteremo il RP tramite Auto-RP:
ip pim autorp listener
Non appena configuriamo R3, inizierà a inviare RP-Announce:
E R2, dopo la configurazione come agente di mappatura, inizierà ad attendere i messaggi RP-Announce. Solo quando ne trova almeno uno, inizierà a inviare RP-Discovery:
Così, una volta che i normali router (PIM RP Listener) ricevono questo messaggio, sapranno dove cercare il RP.
Uno dei principali problemi di Auto-RP è che, per ricevere i messaggi RP-Announce e RP-Discovery, è 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 è stata inventata la modalità PIM Sparse-Dense. Se il router non conosce il RP, funziona in modalità Dense-mode; se lo conosce, in modalità Sparse-mode. Quando sulle interfacce dei normali router è configurato PIM Sparse-mode e il comando ip pim autorp listener, il router funzionerà in modalità Dense-mode solo per il multicast direttamente del protocollo Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Questa 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:
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 l'agente di mappatura. Quindi, passiamo al secondo passo.
2) Configuriamo R2 come agente di mappatura:
ip pim bsr-candidate loopback 0
R2 inizia a inviare messaggi PIM Bootstrap, indicando se stesso come mapping agent:
Questo 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.
3) Non appena il RP riceve un messaggio dal router BSR, invia immediatamente un messaggio unicast all'indirizzo del router BSR:
Dopo di ciò, 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 ip pim autorp listener per i normali router in BSR.
Anycast RP con il Protocollo di Scoperta della Sorgente Multicast (MSDP).
Auto-RP e BSR ci permettono di distribuire il carico sui 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 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.
Nell'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 è 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.
Consideriamo la seguente topologia:
Switch6 trasmette traffico all'indirizzo 238.38.38.38 e finora solo RP-R1 ne è a conoscenza. Gli Switch7 e Switch8 hanno richiesto questo gruppo. I router R5 e R4 invieranno PIM Join a R1 e R3, rispettivamente. Perché? La rotta verso 13.13.13.13 su R5 farà riferimento a R1 in base alla metrica IGP, come anche 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 MSDP. Lo configuriamo 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
Essi stabiliranno una sessione tra di loro e, al ricevimento di un qualsiasi flusso, informeranno il loro RP vicino.
RP-R1, non appena riceve il flusso da Switch6, invierà immediatamente un messaggio MSDP Source-Active in unicast, contenente informazioni di tipo (S,G) — informazioni sulla fonte e sul destinatario del multicast. Ora, quando RP-R3 saprà che esiste una fonte come Switch6, alla ricezione di una richiesta da parte di R4 per questo flusso, invierà una PIM Join verso Switch6, facendosi guidare dalla tabella di routing. Di conseguenza, R1, ricevuta tale PIM Join, inizierà a inviare traffico verso RP-R3.
MSDP funziona su TCP, RP si inviano messaggi keepalive per verificare la vitalità. Il timer è impostato su 60 secondi.
Rimane poco chiara la funzione di separation dei peer MSDP in diversi domini, poiché nei messaggi Keepalive e SA non viene specificata l’appartenenza a un dominio. Inoltre, in questa topologia è stata testata una configurazione con diverse specifiche di dominio — non c'era differenza nel funzionamento.
Se qualcuno può fare chiarezza, sarei felice di leggere nei commenti.
Fonte: habr.com
