Quindi ora abbiamo costruito l'albero condiviso.
A questo punto, se mai il multicast dovesse iniziare, una volta raggiunto l'RP, lo farÃ
vai dal router 3 al router 8, dal router 8 al router 2 e poi al router
1. Quindi siamo pronti a partire.
Okay, lasciami, okay, per ora lascio tutto cosÃ¬ com'Ã¨.
Comincia a diventare un po' disordinato, ma farÃ² del mio meglio.
Ok, quindi ora, sai, un minuto dopo, un'ora dopo, finalmente la fonte
si avvia. Inizia a inviare il suo flusso multicast.
Quindi eccolo qui. Router 4 sulla parte posteriore della testa.
Quale azione intraprenderÃ il router 4 dopo aver ricevuto questo per primo
pacchetto multicast?
In realtÃ farÃ un sacco di cose, quindi ce n'Ã¨ piÃ¹ di una corretta
rispondi qui. Bene, prima di fare qualsiasi cosa, sai, la regola del PIM
Ã¨ che quando ricevi qualcosa, non puoi creare alcun pacchetto PIM.
Non puoi inoltrare alcun pacchetto multicast finchÃ© non crei lo stato nel file
Tabella dei percorsi M. Senza lo stato del percorso M, non puoi fare nulla.
Quindi la prima cosa che questo ragazzo deve fare Ã¨ creare lo stato del percorso M.
Quindi dice, okay, bene, perchÃ© ho ricevuto effettivamente traffico da
source, creerÃ² lo stato s-coma-g, che va da 4.5.4.5 a 39.999.
Quindi questo Ã¨ il nostro s-coma-g.
Ok, quindi in questo caso particolare, interfaccia in entrata, cosa sta succedendo?
avere come interfaccia in entrata?
Bene, sarÃ l'interfaccia in cui si trova effettivamente questo multicast
sto entrando. Esattamente.
Ethernet veloce, 0 barra 1.
Giusto. Quindi questo Ã¨ ciÃ² che avremo proprio qui.
Quale sarÃ il vicino dell'RPF per questa voce?
Quale indirizzo IP inseriremo lÃ¬?
Esatto, Pietro. Giusto.
Dice: guarda, sono l'ultimo router hop.
Sono collegato direttamente alla fonte.
Questo non mi Ã¨ arrivato tramite nessun altro router.
Quindi il prossimo salto vicino sarÃ tutto zeri.
Sono dove tutto inizia proprio qui.
Ora, proprio adesso, cosa ci sarÃ nell'elenco delle interfacce in uscita come lui
crea questo? L'elenco delle interfacce in uscita sarÃ nullo.
PerchÃ© dirÃ , guarda, anche se sto ricevendo questo multicast,
nessuno me lo ha mai chiesto.
Non ho mai ricevuto alcun tipo di richiesta IGMP o PIM per questo.
Quindi Ã¨ nullo. Ora, se avessi fatto un percorso IPM, in questo momento sarebbe tutto ciÃ² che avrei
vedresti questa voce di s-energia per questo stato?
Hai una probabilitÃ del 50% di farlo bene.
SÃ¬ o no? No. La risposta Ã¨ no, non Ã¨ tutto ciÃ² che vedresti.
PerchÃ© mentre i router qui possono avere commedie da star da soli,
un s-coma-g non puÃ² essere da solo.
Una s-coma-g Ã¨, ricordi l'analogia del fratello minore e del fratello maggiore?
Ho detto che la star della commedia Ã¨ il fratello maggiore.
PuÃ² uscire. PuÃ² passeggiare per il quartiere da solo.
Ma il s-coma-g Ã¨ il fratellino di sette anni.
Non lo vogliamo fuori da solo perchÃ© potrebbe accadergli qualcosa.
Quindi deve andare d'accordo con il fratello maggiore.
Quindi dobbiamo creare la voce della commedia stellare se non ne esiste giÃ una.
In questo caso non ne esisteva uno.
Quindi lo popoleremo.
Qui c'Ã¨ un po' di confusione, ma cercherÃ² di inserire tutto.
L'interfaccia in entrata sarÃ veloce.
Ethernet 0 barra 0 punto 34 perchÃ© questa Ã¨ l'interfaccia che porta a
punto d'incontro.
Il nostro vicino PF sarÃ 3 punto 4 punto 3 punto 3.
Un elenco di interfacce in uscita, ancora una volta, sarÃ nullo.
PerchÃ© popoliamo l'elenco delle interfacce in uscita solo con qualcosa se
riceviamo una richiesta di qualche tipo.
E non abbiamo mai ricevuto una richiesta.
Ok, ora abbiamo creato MROUT STATE.
Ma non abbiamo ancora risposto alla domanda: cosa ne facciamo?
primo pacchetto multicast?
Ora che Ã¨ stato creato lo STATO MROUT, cosa ne faremo?
Lo registreremo.
Lo invieremo.
Lo incapsuleremo all'interno di un pacchetto di registri PIM.
Quindi eccolo qui, e sarÃ unicast.
Quindi vediamo se riesco a rendere giustizia a questo qui.
Quindi questo sarÃ unicast da R4 fino a R3.
E una traccia sniffer dirÃ REGISTRO PIM.
Ora, una volta che R3 ottiene quel REGISTRO PIM, proprio come R4 ne ha fatti un sacco
roba contemporaneamente quando ha ricevuto il primo pacchetto, ha creato tutto il file
state e l'ha registrato, beh R3, ne farÃ un sacco
roba contemporaneamente una volta ottenuto questo registro.
PoichÃ© finalmente vede la fonte effettiva, puÃ² creare una voce S-comaG.
Non rimarrÃ² a corto di spazio qui, quindi lo metterÃ² semplicemente
solo le basi.
4.5.4.5, 2.39.999.
Quindi questa Ã¨ la mia voce S-comaG.
E se hai domande su quale sia l'interfaccia in entrata o
qualcosa del genere, quindi in questa particolare voce S-comaG andrÃ² avanti
e metti questo. Quando lo creerÃ , dirÃ , okay, beh, se l'ho giÃ fatto
avevo uno star-comaG esistente, stava semplicemente girovagando e aspettando.
E ora creo un S-comaG perchÃ© effettivamente vedo il multicast.
TornerÃ² al mio star-comaG e a qualunque cosa sia nella mia interfaccia in uscita
elenco lÃ¬, lo copierÃ² nel mio S-comaG.
L'unica situazione in cui ciÃ² non accadrebbe Ã¨ se, cosÃ¬ facendo, tu
avrebbe un duplicato di dove si trova l'interfaccia in entrata S-comaG
uguale all'elenco delle interfacce in uscita.
Non puoi averlo.
Non puoi avere un'interfaccia nell'elenco delle interfacce in uscita che Ã¨ il
stesso dell'interfaccia in entrata.
Questo Ã¨ contro le regole del PIM.
Ma in questo caso non dobbiamo preoccuparci di questo.
Quindi qualcuno tra il pubblico dal vivo ha posto una bella domanda.
Stanno dicendo, quindi Ã¨ un messaggio unicast, giusto?
Quel registro PIM Ã¨ unicast.
Quindi, se avessi due o tre o quattro router tra il router tre e il router
quattro, avrebbero uno stato multicast?
No, non lo farebbero.
PerchÃ© se ci fossero dei router qui in mezzo, vedrebbero e basta
un pacchetto unicast con un indirizzo di origine di quattro, destinazione di tre,
e lo avrebbero semplicemente instradato.
Proprio come se stessero instradando una richiesta telnet o un browser web o un FTP.
Quindi, se ci fossero dei router qui in mezzo in questo momento, il loro percorso M
lo stato non mostrerebbe nulla.
Non sono consapevoli che il multicast sta effettivamente viaggiando attraverso di loro
come unicast. Ok, quindi il router tre crea lo stato S-comaG e poi
lo usa per inoltrarlo effettivamente giÃ¹ dall'albero.
Quindi dice, okay, aprirÃ² questo registro, rivelandolo
il multicast all'interno, lo inoltrerÃ² lungo l'albero, e poi
router otto, quando lo riceverÃ , beh, creerÃ lo stato S-comaG
lui. Lo dirÃ² e basta, perchÃ© stiamo esaurendo lo spazio.
Lo inoltrerÃ quindi lungo l'albero condiviso al router due.
Ora torniamo qui per un secondo.
Prima di parlare di ciÃ² che accade sul router due, torniamo all'appuntamento
punto. Esatto, Brandon, il registro dei pin Ã¨ fondamentalmente un tunnel unicast
per il pacchetto multicast.
In realtÃ , Ã¨ piuttosto interessante che tu ne parli.
Una volta che vai sul router e per prima cosa configuri l'RP su di lui, tu
digli chi Ã¨ l'RP, guarda questo.
Vado e basta, non importa quale router scelgo, ma tutto per
per ragioni di scopo, andrÃ² al router quattro.
Guarda questo. In realtÃ crea un'interfaccia tunnel.
SÃ¬, e se mostri il tunnel di interfaccia zero, in realtÃ dice, pem
tunnel di registrazione.
Ogni router lo avrÃ , perchÃ© in qualsiasi momento un router mai
lo sa, dovrÃ² registrarmi?
Ci sarÃ mai un multicast che mi colpisce e di cui avrÃ² bisogno
iscriversi alla RP?
Quindi, non appena un router sa chi Ã¨ l'RP, lo crea dinamicamente
tunnel di registrazione.
Quindi Ã¨ pronto e in attesa di essere utilizzato nel caso in cui fosse necessario registrarsi
nulla. SÃ¬, quindi Ã¨ davvero bello.
Ok, quindi il router tre ha appena inoltrato il pacchetto multicast.
Ora ho detto che il problema con questi pacchetti di registro Ã¨ che consumano
un po' piÃ¹ di risorse CPU nel router che sta effettuando la registrazione,
il router che sta deincapsulando o deincapsulando il registro.
Quindi il router tre dice: okay, non voglio continuare a ricevere questi registri
pacchetti se questo mi sta facendo lavorare molto duramente.
Preferirei semplicemente ricevere il multicast nativo cosÃ¬ com'Ã¨, multicast puro.
Dice, quindi, per farlo, devo farlo sapere ai miei vicini a monte
nella direzione dell'albero del percorso piÃ¹ breve, questo Ã¨ quello che voglio.
Quindi il router tre dice, okay, ora che ho questo stato s-comage, e cosÃ¬ via
per me, il mio percorso piÃ¹ breve Ã¨ l'interfaccia morte veloce e zero zero.
Giusto, dice, quando faccio una ricerca RPF sulla fonte, quattro, cinque, quattro,
cinque, la mia ricerca RPF dice che la mia strada piÃ¹ breve Ã¨ morire velocemente e a
zero zero. Quindi il router tre invierÃ quindi un altro tipo di pacchetto PIM.
Che tipo di pacchetto PIM invierÃ il router tre a questo punto in ordine
per aprire la sua via piÃ¹ breve?
InvierÃ un PIM s-comagee join, un s-comagee join.
E se ci fossero dei router nel mezzo qui tra questi due ragazzi
che in precedenza non aveva alcuno stato multicast perchÃ© il registro lo era
esaminandoli in modo trasparente, se ci fossero dei router, facciamolo
per il momento mettine uno falso proprio qui, diciamo solo router
x era proprio qui.
Ora, dopo aver ricevuto questa unione a s-comagee, il router x creerÃ s-comagee
stato nella sua tabella m-route.
E creerebbe lo stato di comagee stellare perchÃ© il comagee s non puÃ² vivere
da solo. Ã troppo spaventato per andare in giro per il mondo da solo.
Deve avere il fratello maggiore insieme a lui.
Quindi crea anche uno stato di comagea stellare.
E poi avrebbe inoltrato la s-comagee a monte e alla fine l'avrebbe fatto
raggiungere il router quattro.
Una volta che il router quattro riceve questo messaggio, dice, oh, qualcuno lo sta effettivamente facendo
chiedendomi questo multicast.
Quindi ora nella mia voce s-comagee posso rimuovere la mia interfaccia in uscita nulla
e lo sostituirÃ² con l'interfaccia dove ho appena ricevuto la richiesta,
la richiesta s-comagee, che Ã¨ fast-eathonet00.34.
CiÃ² ora dÃ al router quattro il permesso di iniziare a inoltrare il multicast
nativamente giÃ¹ fast-eathonet00.34.
Ma ricorda, quando Ã¨ arrivata quella connessione s-comagee, il router quattro non necessariamente lo ha fatto
sappi che Ã¨ stato perchÃ© il punto d'incontro lo ha avviato.
Non necessariamente lo sa.
Tutto quello che sa Ã¨ che c'Ã¨ un vicino a valle che vuole aprirsi
il multicast. Quindi il router quattro dice: okay, manderÃ² il multicast nel suo
forma nativa pura lungo questo collegamento, ma non so se il punto d'incontro
ha persino ricevuto il mio registro.
PerchÃ© ricorda, non Ã¨ come TCP.
Non ci sono riconoscimenti o altro qui.
Quando il router quattro ha inviato il registro, lo ha semplicemente inviato nel vuoto e
non aveva idea se l'RP lo avesse effettivamente ottenuto o meno.
Quindi dice, beh, oltre a inviare il multicast nella sua forma nativa
in questo modo fino al router X, devo anche continuare a registrarmi.
Non posso fermarlo.
PerchÃ© finchÃ© il punto d'incontro non conferma di aver ricevuto la mia registrazione,
Devo andare avanti.
Quindi ora il multicast scende da questo albero e il router tre ne ottiene due
copie dello stesso. Ottiene il multicast nativo perchÃ© ora questo percorso Ã¨ stato
aperto. E riceve esattamente lo stesso pacchetto multicast incapsulato
all'interno di un registro.
Ora, il router tre dice: okay, fantastico.
So che il mio percorso piÃ¹ breve verso la fonte sta funzionando.
So che Ã¨ aperto.
PerchÃ© se non funzionasse non avrei ricevuto il multicast normale,
il vero multicast nativo.
Dice cosÃ¬ da quando ho ricevuto il vero multicast, che continua a inoltrare
a valle, dice, ora posso inviare un messaggio di stop al registro.
Sto esaurendo completamente lo spazio qui, ma puÃ² inviare un registro PIM
fermare. E questo, proprio come dice, causerÃ l'arresto del router quattro
registrazione. E ora invierÃ semplicemente il multicast nativo nel suo puro
forma fino al router tre e andrÃ via.
Ora, ho menzionato quando Ã¨ nato il primo pacchetto multicast, quando Ã¨ stato il primo
la registrazione Ã¨ stata non incapsulata, deincapsulata e alla fine Ã¨ riuscita
strada per il router due, ho detto, fermiamoci un secondo.
Torniamo al punto d'incontro perchÃ© il router due andrÃ bene
un sacco di cose.
Quindi torniamo indietro nel tempo.
Portiamo indietro l'orologio di un secondo o due fino a quando Ã¨ proprio cosÃ¬
il primo pacchetto multicast ha colpito il router due.
Beh, indovina un po'?
Router due, quando lo ottiene, crea lo stato S, virgola G, perchÃ© adesso
ha visto il pacchetto.
E lui dice, okay, torna alla sua stella, voce virgola G, e vede
una piccola bandiera lÃ¬ dentro.
Il flag C, che dice, oh, ricordo di aver creato la stella, lo stato virgola G
perchÃ© a direttamente connesso, ecco cosa sta per C, a direttamente
il ricevitore connesso mi ha chiesto questo multicast.
Ho ricevuto un rapporto sull'adesione.
Quindi dice, ciÃ² significa che sono quello che PIM chiama un router foglia.
Sono alla fine del ramo.
E poichÃ© sono un router fogliare, ho l'autoritÃ di aprire il piÃ¹ breve
albero del sentiero. Per quanto mi riguarda, posso allontanarmi dallâalbero condiviso e provarci
ottenere questi pacchetti in modo piÃ¹ efficiente.
Quindi, se assumiamo qui che questo collegamento seriale sia in realtÃ il percorso piÃ¹ breve
tree dal punto di vista del router due, praticamente farÃ esattamente la cosa
la stessa cosa che ha fatto il punto d'incontro.
InvierÃ una S, virgola G join a monte.
E quando il router quattro lo riceverÃ , lo farÃ nell'elenco delle sue interfacce in uscita
ora aggiungi il seriale 010 a quell'interfaccia in uscita.
E ora il multicast nativo inizierÃ a fluire da questa parte.
Una volta che il router due ottiene il multicast nativo, ora dice, okay, fantastico.
Ora ricevo il multicast nativo sul mio albero del percorso piÃ¹ breve.
Ma hmm, sto anche ricevendo copie di quel pacchetto lungo l'albero condiviso.
Non ho piÃ¹ bisogno di quei pacchetti nell'albero condiviso.
Non li voglio.
Quindi rivedi la domanda: cosa fa il router due per provare a fermare il file
i pacchetti scendono dall'albero condiviso?
Giusto. Invia un messaggio di prune PIM.
Esattamente un messaggio di eliminazione PIM, che Ã¨ esattamente lo stesso formato di un'unione PIM
Messaggio. Invece di dire il numero di gruppi a cui si Ã¨ aderito, dice il numero
di gruppi potati.
Quindi manda una prugna PIM.
In questo caso particolare, avrÃ effettivamente la fonte, 4.5.4.5.
AvrÃ il gruppo.
Ma lÃ¬ dentro avrÃ impostato il bit RP, che dice al suo upstream
vicino, ehi, non inoltrarlo alla fonte.
Anche se sto elencando qui l'indirizzo della fonte, non Ã¨ lÃ¬
il messaggio alla fine andrÃ .
Ho bisogno che inoltri questo al punto d'incontro.
Quindi il router otto eliminerÃ la barra zero uno dalla sua interfaccia in uscita
elenco. CreerÃ un messaggio di potatura, che invierÃ poi al router
tre. Il router tre eliminerÃ quindi la sua lista di interfacce in uscita.
E ora il router tre dirÃ : okay, nessuno ha bisogno del multicast
per me piÃ¹. Non ho piÃ¹ interfacce nell'elenco delle interfacce in uscita.
Quindi indovina cosa farÃ ?
ManderÃ una prugna secca verso la fonte.
E cosÃ¬ alla fine, dopo appena un secondo o due, il traffico diminuirÃ
piÃ¹ a lungo, smetterÃ di attraversare il punto d'incontro, e lo farÃ solo
scendere lungo l'albero del percorso di origine direttamente al router due.
Allora, che domande hai?
CiÃ² completa la mia revisione di questo processo nel pubblico dal vivo.
Avete domande?
Peter fa una bella domanda.
Dice: ehi, ricordo qualcosa chiamato registro nullo.
Chi lo invia e a quali condizioni viene inviato?
Ok, quindi eccoci qui nel presente.
In questo momento il multicast sta raggiungendo il router quattro, l'unico in uscita
l'interfaccia del router quattro Ã¨ seriale zero barra uno dimensione zero.
Quindi lo sta mandando giÃ¹ direttamente in quel modo.
Ma il router quattro, dice, beh, ogni pochi secondi ha il suo pensiero.
Il router quattro, ogni pochi secondi, dice che c'Ã¨ una possibilitÃ
qualcun altro negli ultimi secondi potrebbe essersi unito allo stream e aver inviato
la loro richiesta al punto d'incontro.
E forse il punto d'incontro Ã¨ seduto lÃ¬ proprio adesso, a giocherellare con il suo
pollice che dice: amico, vorrei che lo streaming iniziasse perchÃ© ho qualcuno
nuovo chi lo vuole.
Ma ricorda, il punto d'incontro potrebbe essersi dimenticato del flusso.
Potrebbe non avere piÃ¹ uno Stato.
Quindi, quando qualcun altro si Ã¨ unito, si Ã¨ creata una nuova stella, lo stato della virgola G
e il punto d'incontro.
Ma si Ã¨ dimenticato del suo precedente stato S, virgola G.
Non c'Ã¨ piÃ¹. Quindi il router quattro dice, nel caso fosse successo,
InvierÃ² un registro nullo.
Ã circa ogni cinque secondi.
Ogni cinque secondi circa, invierÃ² un registro nullo al router
tre, che in realtÃ non contiene il pacchetto multicast al suo interno.
Fondamentalmente dice semplicemente, ehi, punto d'incontro.
Voglio solo ricordarti che ho attivato questo flusso multicast.
Lo sto inoltrando ad altre persone.
E se lo vuoi, potresti chiedermelo.
Ecco cos'Ã¨ un registro nullo.
Si spegne ogni cinque secondi.
Viene generato dal router quattro perchÃ© Ã¨ quello direttamente connesso
alla fonte. Ed Ã¨ il suo modo di ricordarsi il punto d'incontro, ehi,
vuoi questo?
Ora, se il punto d'incontro lo vuole, invierÃ un join S, virgola G
per riaprire quella strada.
Se il punto d'incontro non lo vuole, manderÃ un altro registro.
DirÃ che non ne ho bisogno.
E cosÃ¬ accadrÃ .
Ogni cinque secondi.
Quindi sÃ¬, quel registro nullo viene sempre generato dal primo router hop.
Il router direttamente connesso all'origine multicast.
Ci sono altre domande?
E sÃ¬, Josh ha fatto una bella domanda.
Ha detto, tornando al router due, quando il router due Ã¨ passato al
percorso piÃ¹ breve, solo Josh vuole solo conferma.
Ha assolutamente ragione.
Il modo in cui il router determina il percorso piÃ¹ breve Ã¨ una volta che guarda
all'indirizzo sorgente di quel multicast, che in questo caso Ã¨ quattro, cinque,
quattro, cinque, cinque, quattro.
Fa un controllo sull'RPF.
Entra nella tabella di routing unicast e dice qual Ã¨ il percorso migliore
Devo tornare a quella fonte?
E potrebbe avere un percorso statico o un percorso EI-JRP o un percorso OSPF.
Ma in questo caso, aveva una specie di percorso che indicava il modo migliore per farlo
tornare alla rete quattro, cinque, quattro avviene tramite seriale 010.
Ecco come ha determinato quale sarebbe stata la sua strada piÃ¹ breve.