Nell'ultimo video, abbiamo esaminato in modo molto dettagliato il processo
viene utilizzato quando creiamo l'albero condiviso, come l'appartenenza a IGMPM
il report ricevuto dal gateway predefinito avvia un PIM, quello che chiamiamo star,
G-join, che procede hop dopo hop fino al punto di incontro.
E abbiamo visto come ciÃ² accade, ogni router dal router, quello predefinito
gateway che ha ricevuto il rapporto di adesione e quindi ciascun router
il percorso che riceve la stella, congiungimento G fino al punto d'incontro,
che ha creato quello che abbiamo chiamato stella, stato del percorso G-em nel nostro routing multicast
tavolo. Quindi una volta che abbiamo quella stella, lo stato del percorso G-em, che Ã¨, non lo faccio
importa quale sia la fonte, una volta che inizia a raggiungere il punto di incontro,
abbiamo una connessione aperta, un percorso aperto, fino al ricevitore.
E questo si basa su ciÃ² che Ã¨ stato mostrato nell'elenco delle interfacce in uscita.
Ok, ora iniziamo effettivamente il multicast e vediamo cosa succede lÃ¬.
Quindi la linea tratteggiata verde in questo caso particolare indica l'albero condiviso
quello Ã¨ giÃ aperto.
Ora non sto mostrando R8 qui, ma sappiamo che R8 Ã¨ tra questi due.
Ora la fonte inizierÃ .
E quello che vedremo Ã¨ quando R4 riceverÃ il multicast nativo
pacchetti dalla fonte, dirÃ , eh, ho un problema qui.
PerchÃ© mi Ã¨ consentito inoltrare questi pacchetti multicast nativi solo se
Ho alcune voci nella mia tabella di routing M che hanno un'interfaccia in uscita
elenco delle interfacce. Ma dirÃ che nessuno me lo ha mai chiesto.
Non ho mai ricevuto alcun rapporto sull'adesione all'IGMP.
Non ho mai ricevuto alcuna adesione PIM da nessuno.
Quindi non ho un posto dove inviarlo.
Eppure potrebbero esserci dei ricevitori lÃ fuori.
Allora cosa faccio?
Bene, con la modalitÃ sparsa PIM, quello che farÃ Ã¨ prendere
quel pacchetto multicast e lo incapsulerÃ all'interno di un unicast.
E questo sarÃ all'interno di un pacchetto PIM.
Quindi ci sarÃ un altro tipo di pacchetto PIM chiamato registro PIM.
Ed Ã¨ quello che vedremo in seguito.
Quindi il registro PIM effettivamente porta.
Ã un pacchetto unicast, unicast da R4 direttamente all'RP.
Quindi vedremo gli indirizzi sorgente R4.
L'indirizzo di destinazione Ã¨ il punto d'incontro.
Il tipo PIM sarÃ un nuovo tipo chiamato registro.
E nel corpo ci saranno effettivamente i nostri dati multicast.
E quando il punto d'incontro lo avrÃ capito, lo deincapsulerÃ , rivelandolo
il pacchetto multicast.
E poi l'RP dirÃ , okay, ho uno stato per questo?
Qualcuno me lo ha mai chiesto?
Bene, in questo caso dirai di sÃ¬, perchÃ© il nostro albero condiviso esiste giÃ
pronto e in attesa.
Quindi lo inoltrerÃ lungo l'albero condiviso.
Ecco come inizierÃ inizialmente il nostro multicast registrando questo
modo. Quindi ora ciÃ² potrebbe continuare potenzialmente indefinitamente.
Giusto? Voglio dire, funziona.
Ottiene il multicast dalla sorgente al ricevitore.
Ma chiede al router connesso alla sorgente e all'RP di funzionare
un po' piÃ¹ difficile avvolgere questa cosa in un unicast e scartarla
dall'unicast dall'altra parte.
Quindi, anche se funziona, consuma un po' piÃ¹ di risorse della CPU.
E certamente se avessimo dozzine o centinaia di flussi multicast in esecuzione
questo, potrebbe potenzialmente essere negativo per l'RP che Ã¨ multicast all'interno.
Quindi cosa succederÃ ?
E lo vedremo nel prossimo segmento in modo piÃ¹ dettagliato, quando ci sarÃ l'appuntamento
Se il punto riceve questo pacchetto di registro pin, in realtÃ ne farÃ un paio
delle cose contemporaneamente.
Numero uno, lo scarterÃ e lo inoltrerÃ lungo l'albero condiviso.
Ne abbiamo giÃ parlato.
La prossima cosa che il punto d'incontro Ã¨ questo multicast nella sua forma nativa pura.
Quindi posso semplicemente inoltrarlo in base al mio percorso M.
Quindi non devo continuare a tormentare la mia CPU con esso.
Vedi, come posso farlo?
Bene, so che il mio vicino a monte lo inoltrerÃ solo a
me se glielo chiedo.
Quindi l'RP invierÃ effettivamente un messaggio di adesione al suo vicino.
Ma questa non Ã¨ una commedia da star perchÃ© in realtÃ conosce la fonte.
Quando arriva il primo multicast, dice, oh, so chi Ã¨ la fonte
Ã¨, 4.5.4.5. Quindi invierÃ quello che viene chiamato un join S, G.
Quando vediamo nella traccia dello snipper, Ã¨ esattamente lo stesso formato di una stella
-comedy join, tranne che elenca l'indirizzo di origine e un paio
anche le bandiere sono diverse.
E questo apre l'albero del percorso piÃ¹ breve dal punto d'incontro a
la fonte. PerchÃ© ricorda, abbiamo parlato di come esiste potenzialmente
piÃ¹ alberi condivisi, giusto?
Se sono un punto d'incontro e ci sono 50 ricevitori diversi sparsi
attraverso la rete potrebbero esserci 50 diversi alberi condivisi.
Ebbene, allo stesso modo, il concetto di albero del percorso piÃ¹ breve proviene da un individuo
punto di vista del router.
Il mio percorso piÃ¹ breve per arrivare a quella fonte Ã¨ che un router potrebbe essere diverso
del percorso piÃ¹ breve per arrivare alla stessa fonte.
Quindi il punto d'incontro, quando riceverÃ questa busta di registrazione, se ne andrÃ
per dire, voglio aprire il mio percorso piÃ¹ breve per arrivare a quella fonte.
PerchÃ© una volta aperto, questi registri si fermeranno.
InizierÃ² a ottenere il multicast puro nella sua forma nativa.
Quindi non appena arriva il registro, oltre a inoltrarlo
in questo modo, questo RP verrÃ inviato, lasciami espandere un po', lo Ã¨
invierÃ² una s, G si unirÃ a monte.
E questo, in R4, aggiungerÃ il segno elettronico veloce a zero, zero nel suo
elenco delle interfacce in uscita.
Ora i nostri quattro diranno: Oh, fantastico.
Ok, ora posso iniziare a inoltrare il multicast downstream nella sua forma pura
forma nativa. Ma indovina un po', continuerÃ a registrarsi.
Quindi ora otterremo due copie di questi pacchetti multicast sul file
RP. Metteremo in funzione il multicast nativo.
E ne otterremo un'altra copia all'interno di questo pacchetto di registro pin.
Ora potresti dire: perchÃ© Ã¨ successo?
PerchÃ© una R4 si ferma a quel punto?
Bene, ecco perchÃ©.
In questa particolare topologia, non la descrive molto bene.
Ma immagina se avessi questo.
Ok, quindi immagina se, sai, ecco la mia fonte.
Ok, abbiamo il router X e abbiamo il PIM RP.
E questo Ã¨ il router cinque.
Ok, quindi qui la mia fonte sta inviando il suo multicast al router cinque.
Il router cinque prende quindi il multicast e lo registra.
Vedi se riesco a disegnare qualcosa qui per indicarlo.
Quindi questa Ã¨ la registrazione.
E ora il router cinque ottiene un join s, g.
Quindi la fonte Ã¨, vediamo qui, qual Ã¨ la fonte del ragazzo?
4.5.4.5 nel mio esempio particolare.
Quindi dice, okay, ecco un'adesione al PIM.
E in realtÃ elencherÃ la fonte e il gruppo.
Ok, beh, quando arriva questa cosa, se ci fosse, come posso esprimerla?
In realtÃ , ecco un esempio migliore.
Metti un router proprio qui al centro.
Ok, quindi questi messaggi PIM hanno tutti un tempo di vita.
Esatto, abbiamo visto come il join PIM star comma g Ã¨ andato allo stesso multicast
indirizzo come il ciao, 2240013.
Ora non l'ho realmente indicato nella traccia dello sniffer, ma proprio come il file
Ciao PIM, ha un tempo da vivere, PIM si unisce e diciamo il suo indirizzo
Ã¨ 55555. Quando l'unione PIM avviene proprio qui, nell'intestazione IP effettiva,
la fonte verrÃ da quel ragazzo.
E la destinazione sarÃ cosÃ¬.
Beh, in realtÃ sarÃ il router.
Questo ragazzo proprio qui, 4.5.4.4.
Diciamo solo questo, diciamo solo che Ã¨ il router 4 per renderlo semplice.
Quindi non c'Ã¨ necessariamente modo per il router 4 di sapere che questo si unisce
in realtÃ ha avuto origine all'RP perchÃ© Ã¨ un salto dopo l'altro.
Quando l'RP lo ha inviato per la prima volta, l'RP lo ha inviato al router Z perchÃ© Ã¨ una virgola
g join conteneva le stesse informazioni.
La fonte era 4.5.4.5.
Il gruppo era 239.999.
E il pacchetto qui aveva un'origine IP dell'RP e una destinazione
router 4. Mettiamolo qui.
In realtÃ no, la destinazione era il router Z perchÃ© Ã¨ hop by hop.
Ã solo un salto.
L'origine IP Ã¨ RP.
La destinazione Ã¨ uguale al router Z.
Quindi ha inviato questa virgola g join perchÃ© l'RP ha detto, okay, so chi Ã¨
la fonte Ã¨. Il mio prossimo vicino Ã¨ il router Z.
Quindi invierÃ² un PIM virgola g join a quel vicino dicendo: ehi
vicino, puoi aprirmi questa strada?
Quindi, quando il router Z lo ottiene, fa la stessa cosa.
Dice che il mio percorso sicuro verso la fonte Ã¨ il router 4.
Quindi creerÃ² un PIM s comma g join e lo invierÃ² al router 4.
Quindi questo si apre man mano che si procede lungo il percorso qui.
Questa interfaccia viene aperta nell'elenco delle interfacce in uscita.
Ma quando il router 4 capisce questo, non ha idea del motivo per cui lo sta ricevendo
Ã¨ perchÃ© il RP ha avviato il processo.
Tutto quello che sa Ã¨ che ha ottenuto una s virgola g join per il router Z.
Non ha idea del motivo per cui il router Z glielo ha inviato.
Solo questo router Z l'ha capito, quel router Z lo ha avviato.
Quindi dice, beh, il router Z mi ha inviato questa virgola g join, ma io sono nel
processo di registrazione.
I due sono totalmente diversi.
Solo perchÃ© un ragazzo mi ha inviato un'iscrizione non significa che dovrei interrompere la registrazione
processo con un altro ragazzo.
ContinuerÃ² comunque a registrarmi perchÃ© non ho piÃ¹ notizie da
RP ancora. Tutto quello che ho sentito Ã¨ il router Z, di cui l'RP otterrebbe due copie
lo stesso pacchetto.
Quando il pacchetto multicast inizia a fluire verso il basso, scorrerÃ in modo nativo
da 4 a Z a RP perchÃ© ormai questa strada Ã¨ stata aperta.
E allo stesso tempo, quando il router 4 ha ricevuto quel pacchetto multicast, ha creato
una copia di esso e lo ha incapsulato in unicast e lo ha trasmesso direttamente in unicast
al RP. Quindi ora l'RP dice, eh, okay, ottime notizie.
Ho appena ricevuto il vero pacchetto multicast nella sua forma nativa pura sul mio
albero del cammino piÃ¹ breve.
Ora so che la mia strada piÃ¹ breve verso la fonte Ã¨ aperta.
Sta scorrendo. Sta funzionando.
Dice: non ho piÃ¹ bisogno di questi messaggi di registro.
Questo mi fa lavorare piÃ¹ del necessario.
Quindi l'RP invierÃ effettivamente quello che viene chiamato un messaggio di arresto del registro PIM
al router 4. Questo Ã¨ ciÃ² che il router 4 sta cercando.
CiÃ² gli farÃ interrompere effettivamente il processo di registrazione.
Quindi so che in questo diagramma non era del tutto chiaro.
Potresti aver detto, okay, bene, quando l'app fermerÃ la cassa,
Voglio mostrarti di no.
Questo non Ã¨. La registrazione continuerÃ finchÃ© il RP non dirÃ esplicitamente:
per favore fermati. Non voglio piÃ¹ vedere questi registri.
Quindi utilizza un messaggio di stop del registro per passare.
In realtÃ , non lo usa per passare al suo albero del percorso piÃ¹ breve.
Lo fa dopo che il suo albero del percorso piÃ¹ breve Ã¨ giÃ stato aperto.
Quindi in realtÃ sono disposto a cambiare la situazione.
LÃ¬, l'RP utilizza i messaggi di stop del registro dopo il suo albero del percorso piÃ¹ breve
Ã¨ confermato e aperto.
Questo Ã¨ il processo di registrazione del PIM.
Quindi andiamo avanti e diamo un'occhiata a questo e vediamo come funziona.
Quindi penso che in questo momento il nostro albero condiviso sia attualmente aperto.
Confermiamo e basta, andiamo sul router 3 su RP e assicuriamoci che sia ancora
ha una stella, voce.
Oh, okay, non lo fa.
Torniamo alla nostra fonte, il nostro ricevitore qui.
Ok, ecco perchÃ©, perchÃ© non si Ã¨ unito al gruppo.
Ok, quindi ora dovremmo averlo.
Ok, quindi ecco la nostra stella, voce.
E inoltre, per quanto riguarda questi timer, questo timer qui Ã¨ come
tutta la vita di questo.
Questo continuerÃ il conto alla rovescia.
E se mai il conto alla rovescia arrivasse a zero, significa che lo rimuoverÃ²
dall'elenco delle interfacce in uscita.
Ma sappiamo che finchÃ© quel ricevitore Ã¨ ancora attivo, purchÃ©
ci sono ancora domande in uscita e rapporti che ritornano, router 2 ciascuno
60 secondi, invieremo un'altra stella, unisciti qui per rinfrescare quello stato.
E anche il router 8 si siederÃ quando lo riceverÃ , invieremo la sua stella,
join per aggiornare quello stato.
Quindi, per esempio, adesso siamo scesi a 233.
Ed Ã¨ tornato indietro.
Vedi, quindi abbiamo iniziato a tre minuti e 23 secondi.
E siamo scesi a circa un minuto.
E poi non l'abbiamo visto, ma sullo sfondo ha ricevuto una stella,
quanto ha aderito ad un aggiornamento, e tutto Ã¨ tornato a questo.
Questo qui, questo timer, Ã¨ il tempo trascorso in totale da questa interfaccia
l'elenco delle interfacce in uscita.
Quindi Ã¨ passato un minuto e quattro secondi da quando abbiamo ricevuto per la prima volta il nostro
prima stella, join che ha causato la creazione originaria di questa voce m-route.
Quindi questa volta continueremo ad aumentare.