Ok, quindi prima di entrare nei dettagli essenziali del PIM come multicast
protocollo di routing, diamo un'occhiata a un livello davvero elevato di ciÃ² che Ã¨ multicast
protocolli di routing, perchÃ© ne abbiamo bisogno, quale problema sono stati progettati
risolvere. Quindi sappiamo di avere questo concetto di sorgenti e ricevitori,
la fonte Ã¨ qualche server lÃ fuori che sta pompando traffico multicast
e colpendo il tuo router, quel router lo lascia cadere perchÃ© non c'Ã¨
idea di dove dovrebbe andare.
E dall'altra parte della rete ci sono i vostri ricevitori, i vostri computer portatili,
i tuoi PC che desiderano quel traffico multicast, ma il loro gateway predefinito lo ha
nessuna idea di dove sia la fonte.
Allora come colleghiamo i due?
E questo Ã¨ l'intero motivo per cui abbiamo bisogno dei protocolli di routing multicast
costruisci quel ramo, per collegarli, per costruire questa distribuzione multicast
albero. Quindi dobbiamo creare quell'albero.
E nel video precedente ho detto che abbiamo due livelli base di alto livello
modi per farlo.
Un metodo, chiamato modello push, viene utilizzato in modalitÃ densa
protocolli, significa semplicemente inondare la rete con quel multicast
traffico. Sicuramente ti occuperai dei ricevitori e di tutto il resto
rami dell'albero che spetterÃ ai router eliminarli
rami per dire, ehi, router upstream, smettila di inviarmelo.
Non ho nessuno a valle che lo voglia davvero.
L'altro modello Ã¨ la modalitÃ sparsa, il che significa, OK, una volta indicato dai ricevitori
il loro interesse per il gateway predefinito, ora deve farlo il gateway predefinito
attivare una sorta di messaggio di partecipazione multicast che dice: OK, invierÃ²
un messaggio a monte che dice: ehi, router sopra di me.
Se mai ricevessi questo messaggio, questo flusso multicast, sono qui.
Lo voglio. La domanda quindi diventa: OK, beh, da dove viene il tuo valore predefinito
il gateway lo invia?
PerchÃ© forse ha cinque o sei router a monte di lui.
A quale invia questo join?
Quindi, per rispondere, ecco una buona analogia che mi Ã¨ venuta in mente.
Pensa agli appuntamenti, giusto?
Ragazzi e ragazze che si frequentano cercando di ritrovarsi.
Quindi un protocollo in modalitÃ densa sarebbe come se tu fossi il ragazzo, tu cammini
in una discoteca e per trovare il tuo compagno perfetto devi semplicemente camminare
fino a ogni singola ragazza che Ã¨ qui che dice: ehi, ti amo.
Vorresti sposarmi?
Ti amo. Vorresti sposarmi?
Ovviamente vieni schiaffeggiato piÃ¹ volte mentre lo fai.
Ma se tutto va bene, prima o poi troverai il tuo ricevitore, giusto?
L'angolo piÃ¹ lontano, la ragazza che beve un sacco di birra, dirÃ :
sÃ¬, voglio sposarti.
E cosÃ¬ ora hai trovato il tuo ricevitore.
Tu sei la fonte.
Lei Ã¨ il ricevitore.
Dovevi prima esaminare tutti gli altri ed essere sfoltito.
Ma alla fine hai trovato chi stavi cercando.
Ã come un protocollo in modalitÃ densa.
Un protocollo in modalitÃ sparsa Ã¨ come, invece di farlo e rischiare tutto
quel rifiuto, usi un servizio di appuntamenti.
Quindi c'Ã¨ questa societÃ intermediaria chiamata servizio di appuntamenti, sai,
qualunque cosa, eharmony.com o qualunque sia il grande in questi giorni.
E la fonte, tu, vai al servizio di appuntamenti e crei un profilo.
E tu dici, ehi, questo sono io.
Sono cosÃ¬ meraviglioso e fantastico.
Guadagno 5 milioni di dollari all'anno.
Guido una Ferrari.
Per favore Sposami.
Giusto? Quindi pubblichi le tue cose lÃ¬ al servizio di appuntamenti.
I destinatari, beh, di tutti i 50 milioni di donne che usano
a quel servizio di appuntamenti, potrebbero essercene tre che partecipano a quell'appuntamento
servizio e dire: oh, sÃ¬, Ã¨ esattamente quello che sto cercando.
E' un po' un idiota.
Ha un sacco di soldi.
Ha una Ferrari.
Mi piacerÃ quel ragazzo.
E cosÃ¬ voi due vi incontrate tramite il servizio di appuntamenti e inizialmente
non potete parlarvi, vero?
Inizialmente il servizio di appuntamenti dice di no, sai, per essere sicuro di questo ragazzo
non Ã¨ una stalker e non Ã¨ pazza, sai, non lo permetteremo
voi ragazzi vi scambiate numeri di telefono, indirizzi e cose del genere.
Dovrai utilizzare il nostro sistema di chat e il nostro sistema di posta elettronica per parlare
l'uno all'altro. Ma alla fine dopo aver scambiato messaggi
il servizio di appuntamenti, ora potete sapere dove vivono gli altri.
Puoi scambiare i numeri di telefono e smettere di usarli.
Puoi comunicare direttamente.
Ecco come funzionano i protocolli in modalitÃ sparsa.
Con i protocolli in modalitÃ sparsa, hai un router seduto da qualche parte
la tua rete che offre tale funzionalitÃ del servizio di appuntamenti.
E cosÃ¬ i ricevitori, una volta che il tuo laptop invia il messaggio IGMP al router,
il tuo gateway predefinito, il tuo gateway predefinito dice, hmm, okay, lo so, ho capito
un ricevitore qui, non ho idea di dove sia la fonte.
il destinatario vuole. Ma so dove si trova il servizio di appuntamenti nei termini
di un protocollo di routing multicast, quel servizio di appuntamenti Ã¨ ciÃ² che chiamiamo a
punto d'incontro, un RP.
Quindi c'Ã¨ qualche router nella rete che tutti i router eseguono multicast
sappi che quel ragazzo Ã¨ il ragazzo da cui andiamo.
Questo Ã¨ il punto d'incontro.
Quindi ora il tuo router dirÃ , okay, creerÃ² qualcosa chiamato
un join, un messaggio di join multicast.
E lo manderÃ² in direzione del punto d'incontro dicendo: ehi,
Ho un tizio quaggiÃ¹ che sta cercando questo gruppo.
E cosÃ¬ alla fine l'unione arriva fino al punto di incontro.
Ora la fonte potrebbe non essere ancora iniziata, ma il punto d'incontro adesso
ha costruito un ramo lungo l'albero dal punto d'incontro fino in fondo
questi router fino al gateway predefinito.
Ora abbiamo aperto un percorso in modo che, se il multicast si avvia, funziona
una direzione in cui puÃ² fluire.
Ora si avvia la sorgente, la sorgente, il server.
Quindi quel server inizia a inviare il suo multicast e colpisce il suo router,
qualche router connesso a quel segmento viene picchiato sul retro
in testa con questo traffico multicast.
Ancora una volta, quel router lassÃ¹ nell'altro angolo della rete
dice che non ho mai avuto notizie da nessun ricevitore, ma so dove si trova l'appuntamento
il servizio Ã¨. So dov'Ã¨ il punto d'incontro.
E entreremo piÃ¹ in dettaglio su questo, ma fondamentalmente incapsula
in unicast. Prende quel pacchetto multicast e lo avvolge all'interno di un unicast
e lo trasmette in unicast al punto di rendezvous.
Una volta che il punto d'incontro lo ottiene, lo decapsula, dice, oh, ecco
multicast. Oh, sÃ¬, so dove va a finire perchÃ© ho ricevuto un'iscrizione
per questo e lo manda giÃ¹ dall'albero.
Quindi Ã¨ cosÃ¬ che nei protocolli in modalitÃ sparsa li colleghiamo inizialmente, giusto?
Quel punto d'incontro Ã¨ il servizio di appuntamenti.
Ma proprio come nella mia analogia, non vuoi la sorgente e il ricevitore
attraversando costantemente il punto d'incontro per parlare tra loro.
Non Ã¨ necessariamente efficiente, giusto?
E se il destinatario fosse in Florida e la fonte fosse nella Carolina del Nord?
ma il punto d'incontro Ã¨ in California?
Beh, in quel traffico il traffico sta diminuendo per arrivare all'appuntamento
punto e ritorno. C'Ã¨ un percorso molto piÃ¹ breve direttamente tra la fonte
e il ricevitore.
Ma prima di poterlo scoprire, dovevamo avviare il multicast
da dove viene, che viene dalla Carolina del Nord.
E ora i Rogers possono passare a quella strada.
Possono dire, OK, grazie, servizio di appuntamenti.
Grazie, punto d'incontro.
Non ho piÃ¹ bisogno di te.
Ora so esattamente dov'Ã¨ la fonte.
Possiamo ottenere il traffico direttamente da lui e possiamo passare a quello
sentiero. Quindi questo Ã¨ un livello davvero elevato di come funzionano i protocolli in modalitÃ sparsa.
Dobbiamo prima unirci al punto d'incontro, esprimere il nostro interesse,
costruire quel ramo.
Il traffico deve iniziare a dirigersi verso il punto di incontro e poi cambia
finito, quindi va direttamente tra la fonte e il destinatario, appuntamento
Il punto non fa nemmeno piÃ¹ parte dell'equazione.
Quindi i protocolli in modalitÃ sparsa utilizzano qualcosa chiamato alberi basati su core o alberi RP
perchÃ© abbiamo un punto d'incontro.
Quindi il punto d'incontro Ã¨ il nucleo dell'albero.
Tutti iniziano andando da lui e poi si allontanano da lui in modo carino
velocemente. OK, quindi l'RPF, nel caso non lo conoscessi, ovviamente l'RPF potrebbe farlo
passare all'albero.
Sono molte cose diverse ma in questo caso particolare significa
inoltro del percorso inverso.
Ora pensa al traffico unicast.
Allontaniamoci dal multicast per un secondo.
Un router riceve un pacchetto unicast diretto a una destinazione 9.9.9.9.
Cosa fa il router?
Il router dice, OK, guarderÃ² l'indirizzo IP di destinazione,
vai nella mia tabella di routing e vedi se ho una sorta di percorso che lo dice
dov'Ã¨ quella destinazione.
Normalmente, per instradare quel pacco e metterlo in viaggio, lo fa
al router interessa la fonte di quel pacchetto?
No, non potrebbe interessarti di meno quale sia l'indirizzo di origine.
In effetti, potresti inserire 0, 0, 0, 0 come sorgente, il router
non mi importerebbe. Per instradare quel pacchetto, tutto ciÃ² che gli interessa Ã¨ il file
destinazione. Ora certamente potresti implementare elenchi di accesso e altro
cose del genere per costringerlo a guardare la fonte.
E puoi effettivamente implementare anche qualcosa chiamato RPF.
Ad esempio, cosa succede se, sai, diciamo che il mio laptop in questo momento Ã¨ seduto
sulla rete 11, 11.qualcosa, quindi ho avuto un indirizzo 11, 11.555.
Questo Ã¨ l'indirizzo del mio portatile.
E scopro, scopro attraverso la vite che sarÃ²
licenziato oggi. Io dico, cosa?
Cavolo, ho passato tanti anni in questa compagnia.
Ho fatto gli straordinari.
Ho sacrificato i miei figli per questa azienda.
Mi licenzieranno.
Questo mi dÃ davvero fastidio.
Quindi dico, sai una cosa?
Prima di andare, so qual Ã¨ l'indirizzo IP del server web della mia azienda.
Ã 77777. Quindi sono un po' abbastanza esperto.
Io dico, sai una cosa?
DistruggerÃ² quel server.
IntascherÃ² quel server con, non so, un qualche tipo di traffico.
Forse richieste di sincronizzazione TCP, giusto?
Lo colpirÃ² con 5 milioni di sincronizzazioni TCP ogni secondo.
Portalo giÃ¹. Quindi ah ah ah.
Vuoi licenziarmi?
Vi farÃ² perdere milioni di dollari nei prossimi due anni
di ore mentre il tuo server Ã¨ inattivo.
Beh, se decido di farlo, non voglio che la gente rintracci quei pacchetti
torniamo a me, giusto?
PerchÃ© non solo verrÃ² licenziato, ma ora sarÃ² in una cella di prigione con
qualcuno a cui non sono particolarmente affezionato.
Quindi non lo voglio.
Quindi dico, hmm, se invierÃ² quelle richieste di sincronizzazione TCP a quel server
per provare a sopraffarlo, voglio assicurarmi che l'indirizzo di origine sia
non me. Non voglio essere 11555, che sono io.
Voglio falsificare l'indirizzo di origine per farlo sembrare qualcos'altro.
Quindi se trovano quei pacchetti, non sapranno mai che provengono da me.
Quindi gli darÃ² un indirizzo IP falso perchÃ© so quando arrivano quei pacchetti
ai router, ai router non interessa quale sia l'indirizzo di origine.
E crollerÃ .
Bene, se sono l'amministratore di rete, c'Ã¨ una cosa che posso fare per evitare
per farlo Ã¨ che posso usare il cosiddetto controllo RPF unicast,
il che significa quando un pacchetto entra in un'interfaccia su un router, prima
Guardo anche l'indirizzo di destinazione, guarderÃ² la fonte
indirizzo e mi pongo una domanda molto semplice.
Quell'indirizzo di origine, se dovessi tornare indietro nella direzione opposta verso
quella fonte, utilizzerei questa interfaccia dove Ã¨ appena arrivata?
Ora sono seduto qui.
Ho 11.555. Ho cambiato intenzionalmente l'indirizzo di origine del mio pacchetto
a qualcosa di completamente falso, come 12, 12, 12, 12.
Bene, Ã¨ arrivato in questa interfaccia.
Ã arrivato velocemente Ethan alle 00 sul router.
Secondo la tabella di routing di questo router, dice, per arrivare a 12, 12
rete, non andrei veloce Ethan a 00.
Uscirei dal serial 11.
Pertanto, se l'amministratore di rete ha configurato il check-in RPF unicast
il router, dirÃ il router, c'Ã¨ qualcosa che non va in questo pacchetto.
Secondo il mio percorso inverso, non percorrerei questa strada per arrivare a 12.
Io andrei da questa parte.
Il pacchetto arrivava nell'interfaccia sbagliata e veniva scartato.
Verrebbe scartato.
E cosÃ¬ ora il mio server non riceverebbe mai quel pacchetto.
Non danneggerebbe mai il server.
Non Ã¨ attivo per impostazione predefinita.
Il controllo RPF Unicast Ã¨ qualcosa che devi abilitare se vuoi farlo
Quello. Ebbene, che rapporto c'Ã¨ con questo?
Quando abiliti il ââmulticast, i protocolli di routing multicast eseguono controlli RPF
la fonte per impostazione predefinita.
Ã un dato di fatto, non puoi impedire loro di farlo.
Lo fanno. Ora, perchÃ© lo fanno?
Lo fanno per il rilevamento del loop.
L'idea Ã¨ che quando arriva un pacchetto multicast, non vuoi semplicemente girare in cerchio
in rete per sempre.
Quindi quello che fanno i router Ã¨ dire, okay, il router sta utilizzando la modalitÃ sparsa
protocolli. Quindi, se sono un router inserito in una rete, diciamo semplicemente che lo sono
il gateway predefinito.
Sono il gateway collegato a questo ricevitore, al mio portatile proprio qui.
E sono appena stato informato tramite IGMP che questo ricevitore desidera ricevere
alcuni multicast. 239-777.
Disegniamolo semplicemente per renderlo chiaro.
Va bene. Quindi, ecco, oh, aspetta solo un secondo.
Allora lo farÃ² in questo modo.
Ecco il mio ricevitore proprio qui come un quadrato.
Lo metteremo come una piccola R.
Ed ecco il gateway predefinito a cui Ã¨ connesso.
Gateway predefinito.
E ha diverse interfacce che portano a monte.
Diremo semplicemente interfaccia uno, due e tre.
Non importa quali siano.
Seriale Ethernet veloce, Ã¨ irrilevante per questa discussione.
Ora, questo router ha appena ricevuto un rapporto di adesione IGMP da
ricevitore. E quel ricevitore vuole ricevere il traffico per il 239-777.
Questo Ã¨ il gruppo a cui vuole partecipare.
Ora, questo router esegue un protocollo di routing in modalitÃ sparsa.
Quindi diremo semplicemente che Ã¨ PIM.
Ã in esecuzione il protocollo di routing multicast indipendente dal protocollo.
Quindi, come parte del PIM, per far funzionare il PIM, dice, okay, lo so
c'Ã¨ un router da qualche parte.
Lo chiameremo qui, che Ã¨ il mio punto d'incontro.
E quindi devo far sapere al punto d'incontro che ho un ricevitore
quaggiÃ¹ chi lo vuole?
Quindi diciamo che questo punto d'incontro Ã¨ 8888.
Quindi questo router, dice, okay, lo so.
Facciamo solo un piccolo fumetto qui.
Dice: so che il PIM RP Ã¨ 8888.
Ora, dice, okay, come posso arrivare al PIM RP?
Ora Ã¨ qui che usa il suo protocollo di routing unicast.
Ho menzionato alcune volte che il routing multicast funziona di pari passo con
il tuo protocollo di routing unicast.
Quindi dice, okay, lasciami entrare nella mia tabella di routing.
E secondo la mia tabella di routing, ho un percorso EI-JRP che dice
per accedere alla rete 8.8 avviene tramite l'interfaccia 2.
Quindi invia un'interfaccia di unione PIM 2.
E alla fine, l'adesione al PIM si fa strada attraverso la rete e ottiene
fino al punto d'incontro.
Quindi questo ora Ã¨ l'albero condiviso, giusto?
Questo Ã¨ l'albero che va dal punto di incontro fino al gateway predefinito.
Ora, questo gateway predefinito, poichÃ© utilizza la modalitÃ sparsa PIMS, dice,
okay, mi aspetto che quando inizia il multicast, ogni volta che inizia,
dovrebbe scendere dal punto d'incontro.
Quindi diciamo che il multicast inizia, ed eccolo qui.
Ecco, viene giÃ¹ in questo modo.
Quindi la fonte Ã¨ 7777.
La destinazione Ã¨ 239.777.
Bene, poichÃ© quest'uomo sta utilizzando la modalitÃ sparsa PIMS, esegue un controllo RPF.
Ma ecco come funziona.
Dice, beh, perchÃ© mi aspettavo che questo multicast arrivasse tramite il
punto d'incontro, dice, su quale interfaccia sarebbe dovuto arrivare?
Ebbene, secondo la mia tabella di routing, per arrivare al punto d'incontro, io
passare tramite l'interfaccia 2.
Eh, questo multicast non Ã¨ arrivato dal punto d'incontro.
Non proviene dall'interfaccia 2.
CosÃ¬ indovinate un po? Lo ucciderÃ².
Questo Ã¨ un fallimento dell'RPF.
Non Ã¨ sceso quello che chiamiamo lâalbero condiviso, lâalbero condiviso
tra il punto di incontro e questo gateway predefinito.
Ha semplicemente fallito il controllo RPF.
Ora diciamo che Ã¨ venuta giÃ¹ cosÃ¬.
Ok, quindi Ã¨ venuta la strada giusta.
Il controllo dell'RPF avrebbe avuto successo.
Passerebbe. Diceva, okay, sono interessato a questo gruppo, e cosÃ¬ Ã¨ stato
accedere all'interfaccia corretta, all'interfaccia 2, che Ã¨ l'interfaccia
portando al RP.
Adesso succede qualcosa di interessante.
Quindi andiamo avanti e rimettiamolo qui.
La sorgente era 777. La destinazione era 239.777.
Ok, quindi puÃ² inoltrare il multicast al client, al ricevitore.
Ora, per la prima volta, questo router dice: oh, finalmente so chi
la fonte Ã¨. L'indirizzo effettivo del server Ã¨ 777.
Ora PIMS-SPAR-SMO dice, okay, potrei continuare a riceverlo dall'appuntamento
punto, ma esiste un percorso migliore?
Esiste effettivamente un percorso piÃ¹ breve per arrivare a quella fonte che sarebbe di piÃ¹
efficiente? Quindi torna alla sua tabella di routing.
Dice, okay, ora lasciami fare una ricerca RPF a riguardo.
E lui dice, oh, ecco, ho un percorso che corrisponde a quello, quello
Ho imparato tramite EIGRP.
Ancora una volta, potrebbe essere appreso tramite RIP o OSPF.
Non ci interessa. Dice che avviene tramite l'interfaccia 1.
Quindi ora PIM fa qualcosa di speciale.
Invia un altro PIM in questo modo.
Entreremo in tutti i dettagli di questo.
E dice, questo Ã¨ per la sorgente 777, destinazione 239.777.
E l'adesione al PIM arriva fino in fondo.
E diciamo che la fonte Ã¨ proprio qui.
In realtÃ Ã¨ lÃ¬ che si trova il server.
E ci sono stati un sacco di router nel mezzo.
Quindi ecco un router.
Ecco un router.
Ed ecco un router.
E sono tutti collegati cosÃ¬.
Supponendo che tutti questi router sappiano come raggiungere la rete 777, quello
l'adesione speciale al PIM sarebbe arrivata fino in fondo e alla fine ce l'avrebbe fatta
questo router connesso alla sorgente.
E questo ora ha aperto lâalbero del percorso piÃ¹ breve.
Nota che qui abbiamo due alberi diversi.
Abbiamo quello blu e quello verde.
E il punto blu fino al gateway predefinito era chiamato albero condiviso
o talvolta chiamato albero RP.
A volte potresti vedere l'acronimo RPT.
Ha funzionato, ma potrebbe non essere il percorso piÃ¹ efficiente.
Questo albero verde Ã¨ l'albero del percorso piÃ¹ breve.
Ma non sapevamo cosa fosse finchÃ© non abbiamo saputo dov'era la fonte
abbiamo ricevuto il nostro primo pacchetto multicast.
E quindi ora che abbiamo aperto quell'albero, il router dice, okay,
a questo punto, per un breve momento, la prossima volta che avrÃ² il multicast
pacchetto, potrebbe provenire da uno di due posti.
Lo accetterÃ² sull'interfaccia due perchÃ© potrebbe provenire ancora da lÃ¬
il punto d'incontro.
E ora se arriva sull'interfaccia uno, lo accetterÃ² anche perchÃ© io
cercato di aprire questa strada.
Ho intenzionalmente provato ad aprire questo percorso sperando che il traffico multicast
scenderÃ da questa parte.
Quindi ora se il multicast arriva sull'interfaccia tre, sarÃ un fallimento RPF.
PerchÃ© il router dice, ehi, interfaccia tre, quello non Ã¨ l'albero condiviso
e non Ã¨ l'albero del percorso piÃ¹ breve.
Ma se scende uno di questi supererÃ il controllo RPF.
E una volta che il multicast inizia effettivamente a fluire e ad entrare nell'interfaccia
numero uno, ora il gateway predefinito dirÃ , fantastico!
Ricevo il traffico multicast nel modo piÃ¹ efficiente possibile
tramite l'albero del percorso piÃ¹ breve.
Non ho piÃ¹ bisogno di prenderlo dal punto d'incontro.
Quindi invierÃ effettivamente un messaggio di eliminazione PIM in questo modo, che verrÃ eliminato
da questo albero. E ora il multicast scorrerÃ nel modo piÃ¹ breve
percorso dell'albero fino a quando il destinatario non lo desidera piÃ¹.
Quindi questo Ã¨ un livello davvero elevato di come funziona la modalitÃ sparsa PIM.
Ma ho fatto tutto questo per mostrarti che vengono effettuati i controlli dell'RPF.
Tutto dipende da dove il router si aspetta di ricevere il multicast.
Se si aspetta che arrivi dal punto d'incontro, lo farÃ
diciamo, guarda, il punto d'incontro si trova sull'interfaccia uno o sull'interfaccia sette,
e lo apprende dal suo protocollo di routing.
Ã lÃ¬ che mi aspetto di ottenere inizialmente il multicast.
Se proviene da qualsiasi altra interfaccia, lo ucciderÃ².
Lo lascerÃ² cadere.
Non doveva andare cosÃ¬.
Ma una volta che sa qual Ã¨ la fonte e cerca di aprirla piÃ¹ brevemente
percorso dell'albero, ora l'RPF avrÃ successo.
PasserÃ se il multicast scende lungo l'albero del percorso piÃ¹ breve.
Quindi, come determiniamo l'interfaccia di ingresso corretta?
Come possiamo essere sicuri che l'RPF abbia successo o passi in base al tipo?
di albero che aspettiamo?
Ci aspettiamo che scenda dall'albero centrale, altrimenti noto come
Albero RP? Oppure ci aspettiamo che il traffico scenda dall'albero di origine?
Ora, potrebbe dipendere dal tipo IGP specifico.
Di cosa sto parlando lÃ¬?
PIM non Ã¨ l'unico protocollo di routing multicast.
Ce ne sono altri.
Ad esempio, MOSPF, OSPF multicast.
Probabilmente puoi indovinare se sto usando OSPF multicast per capire
quale sia l'interfaccia corretta per andare all'RP, o l'interfaccia corretta
per andare alla fonte, si basa sulle rotte OSPF.
MOSPF non puÃ² eseguire il controllo RPF in base a RIP o EIGRP.
Ha bisogno dell'OSPF. Ce n'Ã¨ un altro chiamato DVMRP, Distance Vector Multicast
Protocollo di instradamento.
E' un po' strano.
In realtÃ crea la propria tabella unicast separata solo per eseguire controlli RPF.
La tabella DVMRP.
Non usa nient'altro.
La cosa meravigliosa del PIM, Protocol Independent Multicast.
Il protocollo indipendente significa che il PIM dice: non mi interessa.
Quando eseguo un controllo RPF, andrÃ² nella tabella di routing.
Non mi interessa se riesco a trovare un percorso che sia un percorso statico, un percorso connesso,
EIGRP, RIP, OSPF.
Non mi interessa. FinchÃ© riesco a trovare qualcosa per fare il controllo sull'RPF,
SarÃ² felice. Ecco perchÃ© PIM Ã¨ cosÃ¬ popolare perchÃ© ti consente di utilizzare
qualunque protocollo di routing IGP desideri.
Non dipende da quello.