Introduzione
Questo articolo continua la serie su IP Multicast. Daremo un’occhiata a come funziona il multicast IP di base. Vedremo poi come funziona il PIM Dense Mode (PIM-DM), come configurarlo e come risolvere i problemi. Questo dovrebbe riscaldarci prima di affrontare il leggermente più complesso e più scalabile PIM Sparse Mode in un articolo successivo.
L’articolo iniziale sul multicast contiene link ai principali gruppi di lavoro IETF alla fine. Può essere trovato a The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Lo scopo di un protocollo di routing multicast è di permettere ai router di lavorare insieme per consegnare in modo efficiente copie di pacchetti multicast ai ricevitori interessati. Nel processo di fare questo, il protocollo di routing multicast probabilmente fornisce anche un meccanismo per i vicini per scoprire e rintracciare i router vicini che utilizzano anch’essi il protocollo di routing multicast.
Come abbiamo visto nell’ultimo articolo, i computer interessati a ricevere un flusso di pacchetti multicast utilizzano IGMP per notificare i router adiacenti. I router poi usano il protocollo multicast per organizzare una copia del flusso di pacchetti multicast da inviare a loro in modo che possano inoltrarlo sulla LAN che contiene il ricevitore. Non abbiamo fatto menzione di ciò che accade all’estremità sorgente del flusso di pacchetti. In IP multicast, non c’è un protocollo per la fonte per comunicare o registrarsi o notificare i router. La sorgente inizia semplicemente a inviare pacchetti IP multicast, e sta ai router vicini fare la cosa giusta. (Quale sia la “cosa giusta” dipende dal protocollo di routing multicast).
L’immagine seguente mostra una sorgente che invia un pacchetto multicast in rosso, e i router a valle che duplicano il pacchetto e lo inondano ad altri router e infine a tutti i segmenti LAN. Come vedremo tra poco, questo è il comportamento iniziale (e periodico) del protocollo di routing multicast PIM (Protocol Independent Multicast) di Cisco, quando agisce in modalità Dense.
Nota nell’immagine precedente che le frecce blu inoltrano le copie del pacchetto multicast in modo organizzato. Ci possono essere due copie di ogni pacchetto che arrivano in alcuni router o segmenti LAN. Ma i router non inoltrano i pacchetti “all’indietro”. Questa è una buona cosa: pensate a cosa potrebbe succedere se il router E dovesse inoltrare una copia del pacchetto che ha ricevuto da C al router B. B potrebbe poi inoltrare il pacchetto ad A, che potrebbe inoltrarlo a C, e così via, in un loop di inoltro? Questo sarebbe una sorta di equivalente a livello 3 di ciò che accade a livello 2 quando Spanning Tree è disabilitato in una topologia a loop: un buon modo per sprecare molta larghezza di banda e capacità dei router.
Per prevenire i loop di inoltro multicast, IP multicast esegue sempre un controllo RPF, di cui parleremo tra poco.
In aggiunta al controllo RPF, i protocolli di routing multicast come PIM possono anche lavorare per prevenire le inefficienze. Per esempio, il router E nell’immagine non ha bisogno di ricevere due copie di ogni pacchetto multicast (una da B, una da C).
Il protocollo di routing multicast determina quali interfacce inviare copie (o non inviare copie). Come suggerisce l’immagine sopra, l’inoltro multicast avviene lungo alberi logici, percorsi ramificati attraverso la rete. Tutte le informazioni sull’inoltro multicast sono memorizzate nella tabella di stato multicast, che alcuni chiamano la tabella di routing multicast. Queste informazioni possono essere visualizzate con il comando molto utile, show ip mroute. Diamo una breve occhiata ad un esempio di output dal comando show ip mroute (con PIM Dense Mode in esecuzione).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Per capire questo, nota che gli indirizzi che iniziano con 224-239 sono indirizzi IP multicast o gruppi. (Il gruppo si riferisce al gruppo di ricevitori per quell’indirizzo di destinazione multicast).
La voce che inizia con (*, 233.1.1.1) è una voce di albero multicast condiviso, a volte indicata come una voce (*, G). (G qui è solo 223.1.1.1.1). PIM-DM non li usa per l’inoltro dei pacchetti, ma elenca le interfacce con un ruolo nel multicast (noto ricevitore IGMP o vicino PIM) come interfacce in uscita sotto tali voci.
La voce che inizia con (172.16.16.1, 233.1.1.1) è indicata come una voce (S, G). S è la fonte, G è il gruppo. Se preferisci, pensa a questo come a sorgente e destinazione nell’intestazione IP (dato che è dove appaiono effettivamente nei pacchetti). Questa voce è un albero multicast specifico alla fonte per un particolare gruppo multicast. Ci sarà generalmente una voce di questo tipo per ogni fonte e gruppo. Nota che il next hop del routing unicast appare come il vicino RPF, e l’interfaccia in entrata è l’interfaccia RPF, l’interfaccia usata dal routing unicast verso la sorgente 172.16.16.1. L’elenco delle interfacce in uscita mostra che qualsiasi pacchetto da 172.16.16.1 con destinazione 233.1.1.1 ricevuto su FastEthernet1 sarà copiato su Ethernet0.
Puoi disegnare l’albero di inoltro multicast per un particolare (S, G) per scopi di risoluzione dei problemi. Per farlo, eseguite il comando show ip mroute su ogni router. Prendi una copia della tua mappa di rete e disegna una freccia in uscita per ogni interfaccia nella lista delle interfacce in uscita (“OIL” o “OILIST”). Ti ritroverai con un diagramma simile all’immagine qui sopra.
Le bandiere di stato che potresti vedere nell’output di PIM-DM show ip mroute:
- D = Dense Mode. Appare solo sulle voci (*, G). Il gruppo sta operando in modalità Dense.
- C = Directly Connected Host (IGMP!)
- L = Local (Il router è configurato per essere un membro del gruppo multicast).
- P = Pruned (Tutte le interfacce OILIST impostate su Prune). Il router generalmente invia Prune al suo vicino RPF quando questo accade.
- T = Inoltro tramite Shortest Path Tree (SPT), indica almeno un pacchetto ricevuto / inoltrato.
- J = Join SPT. Sempre attivo nella voce (*,G) in PIM-DM, non significa molto.
Cos’è il controllo RPF, e perché?
L’inoltro multicast IP esegue sempre un controllo RPF. RPF sta per Reverse Path Forwarding. L’obiettivo del controllo RPF è quello di cercare di prevenire un ciclo di inoltro dei pacchetti multicast in modo semplice. Per ogni flusso multicast, il router multicast controlla l’indirizzo sorgente, quale dispositivo ha inviato il multicast. Poi cerca il mittente nella tabella di routing unicast, e determina l’interfaccia che userebbe per inviare pacchetti unicast alla sorgente multicast. Questa interfaccia è l’interfaccia RPF, quella su cui il router “si aspetta” di ricevere i multicast. Pensala come l’interfaccia “ufficialmente approvata” per ricevere multicast da quella particolare sorgente. Il router memorizza l’interfaccia RPF come parte delle informazioni di stato multicast per quella particolare sorgente e quella particolare destinazione multicast (gruppo).
Quando un pacchetto multicast viene ricevuto dal router, il router tiene traccia di quale interfaccia il pacchetto è arrivato. Se il pacchetto è il primo pacchetto da una nuova fonte, l’interfaccia RPF viene determinata e memorizzata nella tabella mroute, come appena discusso. Altrimenti, il router cerca la sorgente e il gruppo multicast nella tabella mroute. Se il pacchetto è stato ricevuto sull’interfaccia RPF, il pacchetto viene copiato e inoltrato su ogni interfaccia in uscita elencata nella tabella mroute. Se il pacchetto è stato ricevuto su un’interfaccia non RPF, viene scartato. Se il router fosse una persona, questo sarebbe l’equivalente di “Perché quella persona mi manda questo? Devono essere confusi, ignorerò quello che mi hanno appena mandato.”
Il router inoltre non rimanda una copia di un pacchetto fuori dall’interfaccia in cui è arrivato (l’interfaccia RPF). In altre parole, anche se il router vicino sull’interfaccia RPF richiedesse in qualche modo di ricevere copie di un flusso multicast, il router non aggiungerà l’interfaccia RPF alla lista delle interfacce in uscita che ricevono copie del flusso multicast. Questo protegge da qualsiasi tipo di errore di protocollo che porta due vicini in uno stretto loop di inoltro multicast.
Il router E sta anche probabilmente ignorando uno dei due flussi di pacchetti, in base al fatto che B o C siano collegati all’interfaccia RPF. Anche con percorsi a costo uguale, normalmente solo un’interfaccia viene scelta come interfaccia RPF. Quindi se hai due link che collegano due router, solo uno sarà tipicamente usato per il multicast da qualsiasi subnet sorgente.
Vedi comunque il comando ip multicast multipath (nuovo in Cisco IOS versione 12.0(8) T, 12.0(5) S). Con questo comando, usato correttamente, ci può essere un bilanciamento del carico per diverse fonti per un particolare gruppo multicast. Poiché questo è per sorgente e non per flusso, diventa davvero più simile al load splitting. Potrebbe non essere molto bilanciato.
Il bilanciamento del traffico per un flusso di pacchetti (una sorgente e un gruppo) su due link tra due router può anche essere fatto usando tunnel GRE tra interfacce di loopback, anche se potrei preoccuparmi delle implicazioni sulle prestazioni di fare questo con un flusso ad alta larghezza di banda.
A proposito, questo ci dice anche come dirigere il multicast IP su link di nostra scelta. Controlliamo dove va il traffico multicast controllando il controllo RPF. Se un router non impara i percorsi verso una sorgente multicast su qualche interfaccia, allora quell’interfaccia non sarà l’interfaccia RPF. Così, con i protocolli vettoriali a distanza e il “route starvation” (non pubblicizzare una rotta a un vicino), possiamo dirigere o dirigere il multicast.
Vedremo più avanti che qualsiasi innesto o join PIM viene inviato fuori dall’interfaccia RPF, verso la sorgente (o RP, in modalità PIM Sparse). Controllando dove questa attività ha luogo, controlliamo su quali link il multicast viene inoltrato. Le voci mroute statiche (rotte statiche verso la sorgente per scopi di controllo RPF del multicast) sono un altro modo di dirigere il traffico multicast. Se/quando parleremo di Multicast MBGP (Multiprotocol BGP for Multicast), vedremo che MBGP ci fornisce anche un modo per dirigere o controllare i link usati dal traffico multicast. Notate anche che se l’interfaccia RPF non ha IP multicast abilitato, allora in effetti il router sta aspettando pacchetti dove non li riceverà. L’interfaccia RPF dovrebbe sempre essere un’interfaccia dove IP multicast è abilitato.
PIM Dense Mode – Panoramica
Protocol Independent Multicast ha due modalità, Dense Mode e Sparse Mode. Questo articolo ha spazio solo per coprire il primo. Arriveremo a PIM-SM nel prossimo articolo.
PIM Dense Mode (PIM-DM) usa un approccio abbastanza semplice per gestire il routing IP multicast. L’assunzione di base dietro PIM-DM è che il flusso di pacchetti multicast ha ricevitori nella maggior parte dei luoghi. Un esempio di questo potrebbe essere una presentazione aziendale da parte del CEO o del presidente di una società. Al contrario, PIM Sparse Mode (PIM-SM) presuppone un numero relativamente inferiore di ricevitori. Un esempio potrebbe essere il video di orientamento iniziale per i nuovi dipendenti.
Questa differenza si mostra nel comportamento iniziale e nei meccanismi dei due protocolli. PIM-SM invia multicast solo quando viene richiesto. Mentre PIM-DM inizia inondando il traffico multicast, e poi fermandolo ogni link dove non è necessario, utilizzando un messaggio Prune. Penso al messaggio Prune come un router che dice ad un altro “non abbiamo bisogno di quel multicast qui adesso”.
Nelle vecchie versioni di Cisco IOS, PIM-DM inondava nuovamente tutto il traffico multicast ogni 3 minuti. Questo va bene per il multicast a basso volume, ma non per i flussi di pacchetti multicast a più alta larghezza di banda. Le versioni più recenti di Cisco IOS supportano una nuova caratteristica chiamata PIM Dense Mode State Refresh, dalla 12.1(5)T. Questa caratteristica usa un messaggio di aggiornamento dello stato PIM per aggiornare lo stato Prune sulle interfacce in uscita. Un altro vantaggio è che i cambiamenti di topologia sono riconosciuti più rapidamente. Per impostazione predefinita, i messaggi di aggiornamento dello stato PIM vengono inviati ogni 60 secondi.
Considera i router E e F nell’immagine sopra. Quando due router PIM-DM si connettono a una LAN, vedranno i pacchetti multicast l’uno dall’altro. Uno dovrebbe inoltrare i pacchetti alla LAN, e l’altro no. Entrambi inviano messaggi Assert. La migliore metrica di routing vince, con l’indirizzo IP più alto come spareggio. Se stanno usando diversi protocolli di routing, uno schema di metrica di routing ponderato, un po’ come la distanza amministrativa, stabilisce quale router deve essere il Forwarder (inoltrare i pacchetti multicast sulla LAN). Il Forwarder può essere messo a tacere da un Prune da un router a valle senza ricevitori, se non ci sono anche ricevitori sul segmento LAN. I router a valle potrebbero dover regolare il loro vicino RPF, per riflettere il vincitore del processo di Assert.
Per ripeterlo in dettaglio: quando il traffico multicast viene ricevuto su un’interfaccia non-RPF, viene inviato un messaggio Prune, a condizione che l’interfaccia sia point-to-point. Questi messaggi Prune sono limitati nel tasso, per assicurarsi che il loro volume (potenzialmente, uno per ogni multicast ricevuto) non causi ulteriori problemi.
Se l’interfaccia non-RPF è una LAN, viene inviato un messaggio Assert. I router non-Forwarder poi inviano un Prune sulla loro interfaccia RPF se non hanno bisogno del flusso multicast. Solo uno di questi Prune viene inviato, al momento della transizione per non avere interfacce nella Outgoing Interface List (OILIST). Il ricevitore LAN Prune ritarda l’azione per 3 secondi, in modo che se un altro router LAN ha ancora bisogno del flusso multicast, può inviare un messaggio PIM Join per contrastare (annullare) il Prune. (“Yo, quel router non ne ha bisogno, ma io sì!”)
Supponiamo che un router abbia effettuato il Prune, e qualche tempo dopo un ricevitore richieda il flusso multicast con un messaggio IGMP. Il router invia quindi un messaggio Graft. In effetti, “ehi, ho bisogno di quel flusso multicast qui adesso”.
L’immagine seguente illustra questo, dichiaratamente in forma un po’ compressa.
Spiegazione dell’immagine:
(1), forse il router E sceglie B come suo vicino RPF, basato sull’instradamento unicast alla sorgente. Poi E riceve un pacchetto multicast sull’interfaccia punto-punto da C. Invia un Prune a tasso limitato a C.
(2), i router E e F sulla LAN si scambiano pacchetti Assert, quando E o F vedono il multicast inoltrato dall’altro dei due. Supponiamo che E vinca, in base alla metrica di routing unicast o all’indirizzo. Allora F sa di non inoltrare multicast sulla LAN. Si noti che G e H non sono coinvolti, poiché l’Ethernet è la loro interfaccia RPF.
(3), supponiamo che il router G non abbia ricevitori a valle. Può quindi inviare un Prune LAN al Forwarder per la LAN, il router E.
(4), se il router H ha ricevitori locali o a valle, risponde con un Join LAN.
(5), supponiamo che il router D non abbia ricevitori a valle o locali e abbia inviato un Prune a B. Supponiamo che qualche tempo dopo uno dei PC alla sua destra gli invii un messaggio IGMP per lo stesso gruppo multicast. Il router D può quindi inviare un innesto PIM a B, chiedendo a B di riprendere l’invio del gruppo multicast specificato.
Protocollo PIM e tipi di pacchetti
PIM è un protocollo di routing completo, con vari tipi di messaggi. Non voglio dilungarmi sui diversi messaggi. Ma penso che valga la pena dare una breve occhiata, dato che ci dice qualcosa sul protocollo.
PIM usa i messaggi Hello per scoprire i vicini e formare le adiacenze. L’Hello viene inviato all’indirizzo multicast locale All-PIM-Routers, 224.0.0.13, ogni 30 secondi (PIMv1 usa AllRouters, 224.0.0.2). Ogni LAN ha un PIM Designated Router (DR), usato in modalità PIM Sparse. È anche il Querier IGMPv1: l’indirizzo IP più alto sulla LAN. Il comando show ip pim neighbor mostra i vicini e le informazioni di adiacenza e timer.
Chiarimento aggiunto il 12/11/2004: IGMP querierer e Designated Router sono i due ruoli in questione. Vedi qui.
In IGMP versione 1, “Il DR è responsabile dei seguenti compiti:
- Invio del registro PIM e dei messaggi PIM join e prune verso l’RP per informarlo sull’appartenenza al gruppo host.
- Invio dei messaggi IGMP host-query.”
In IGMP versione 2, sono disaccoppiati. Il querelante IGMP è eletto in base all’IP più basso della LAN. PIM seleziona il DR per l’IP più alto sulla LAN, per inoltrare i multicast alla LAN. (Questo scarica il lavoro).
PIM ha anche un messaggio Join/Prune, usato come descritto sopra. Ci sono anche i messaggi Graft e Graft ACK, il che ci dice che il Graft è fatto in modo affidabile (a differenza del mondo reale?).
E c’è il messaggio PIM Assert.
PIM-SM ha altri 3 tipi di messaggi: Register, Register-Stop, e RP-Reachability (non in PIMv2).
Configurare PIM Dense Mode
Configurare PIM-DM è facilissimo rispetto a tutto quanto sopra.
Globalmente, abilita il multicast routing con il comando:
ip multicast-routing
Poi su ogni interfaccia che vuoi partecipare al multicasting, abilita IP multicast e PIM con il comando interface:
interfaccia …
ip pim dense-mode
In realtà, è meglio configurare la modalità sparse-dense:
interfaccia …
ip pim sparse-dense-mode
La ragione è che questo ti permette semplicemente di migrare alcuni o tutti i gruppi multicast in modalità Sparse, facendo sapere al router un Rendezvous Point. E puoi anche farlo senza riconfigurare molti router o interfacce di router.
Puoi configurare reti stub per il semplice IP multicast. L’idea è di non eseguire PIM su parti stub della rete, come piccoli siti remoti, per semplicità. Questa è un’idea particolarmente buona con i router che non sono sotto il tuo controllo: non vuoi che condividano l’instradamento multicast con i tuoi router. Elimina anche il flooding PIM-DM verso tali router (con le vecchie versioni di Cisco IOS).
Per configurare lo stub multicast, configura
ip igmp helper-address a.b.c.d
su qualsiasi interfaccia LAN dei router stub con potenziali ricevitori multicast. L’indirizzo a.b.c.d è l’indirizzo del router centrale che parla PIM. Sul router centrale, si configura un filtro per escludere qualsiasi messaggio PIM che il vicino stub potrebbe inviare, con:
ip pim neighbor-filter access-list
Vedi anche la guida ai comandi all’URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Ci sono diversi comandi show per aiutare a risolvere i problemi di IP multicast. Quelli che mi piacciono di più:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Siccome lo spazio è limitato, ti rimando al Command Reference per gli esempi.
Una nota per la risoluzione dei problemi: se hai un multicast ad alta larghezza di banda nella tua rete, assicurati di usare il Prune State Refresh nelle nuove versioni di Cisco IOS se stai usando la modalità sparse-dense. Mi preoccupo dei router che “dimenticano” di avere un RP e tornano alla modalità densa, con flooding periodico. Questo potrebbe essere un evento accidentale raro, ma potrebbe davvero rovinare la vostra mattinata! Potresti anche voler considerare le tecniche di robustezza dell’RP, un argomento per il nostro successivo articolo su PIM-SM o Rendezvous Point.
In conclusione
Il libro consigliato per molti argomenti di multicast: Sviluppare reti IP Multicast: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Un altro link multicast di Cisco estremamente buono può essere trovato qui.
Prossimo articolo: scalare con PIM Sparse Mode.