Abbiamo sempre visto che quando mostri il percorso IPM, Ã¨ molto possibile
che potresti semplicemente avere una voce da star-comagee, giusto?
Quindi, se non c'Ã¨ flusso multicast ma hai ricevuto un comagee stellare
unisciti, avrai lo stato di comagee da star.
E quindi significa che sono pronto.
Sto aspettando di inoltrare questo traffico multicast.
Qualcuno me lo ha chiesto.
Una voce s-comagee non puÃ² stare da sola.
Non posso stare da solo.
Quindi, in altre parole, quando il router 2 qui crea questa voce s-comagee, he
deve anche creare una voce star-comagee.
I due devono andare insieme.
Quindi, anche se non ha mai ricevuto un rapporto di adesione all'IGMP, anche se lui
non ho mai avuto una stella-comagee del PIM che si unisse con quel set di caratteri jolly, una volta che lui
crea una voce s-comagee, deve creare una voce star-comagee come
BENE. Entrambi devono essere lÃ¬.
Quindi, s-comagee, l'analogia che uso a volte Ã¨ pensare alla star-comagee
come se fosse come il fratello maggiore e il s-comagee come se fosse come il piccolo
fratello, vero? Il fratello maggiore che ha 15 anni puÃ² andarsene
casa e passeggiare per il quartiere e andare in bicicletta da solo.
Il fratellino che Ã¨ il comagee che ha solo 7 anni, non gli Ã¨ permesso
farlo a meno che il Grande Fratello non vada con lui.
Quindi non so se ti aiuteranno o no, ma ecco fatto.
Inoltre, una volta che il traffico inizia a scorrere lungo il percorso piÃ¹ breve, Ã¨ il
voce s-comagee utilizzata per inoltrare effettivamente quel traffico.
Quindi quello che voglio dire Ã¨ che vedrete la star-comagee che ha un po' di estroversi
elenco delle interfacce e vedrai l's-comagee che ha un'interfaccia in uscita
elenco. Qualunque cosa ci sia nell'elenco delle interfacce in uscita dell's-comagee, questo Ã¨
quello importante.
Questo Ã¨ ciÃ² che viene utilizzato per inoltrare effettivamente il multicast.
Quando percorre la strada piÃ¹ breve, se percorre quella condivisa
percorso, quindi la voce star-comagee Ã¨ ciÃ² che determina l'inoltro del file
traffico. Un paio di cose aggiuntive qui che voglio menzionare.
Non ho molta ridondanza in questa particolare topologia qui.
E se avessi qualcosa del genere?
Eliminiamo questa riga proprio qui.
Diciamo che abbiamo un interruttore e due vicini, due vicini a monte.
Quindi, in altre parole, in realtÃ non si tratta nemmeno di affrontare il passaggio.
Mettiamola cosÃ¬.
Il router uno potrebbe utilizzare il router due o il router quattro per raggiungere la fonte.
Quindi in questo particolare diagramma, si spera sia molto chiaro ciÃ² che accade
il punto d'incontro non Ã¨ il percorso piÃ¹ breve perchÃ© abbiamo quattro router
passare per arrivare alla fonte dove possiamo passare solo attraverso due router
se passiamo attraverso il router due o il router quattro.
Quindi la domanda ora Ã¨: ok, quando il router deve aprire il suo punto piÃ¹ corto
percorso, dirÃ , hmm, ho percorsi piÃ¹ brevi ridondanti.
Potrei andare tramite il vicino due o il vicino quattro.
Quindi la domanda Ã¨: dove andrÃ ?
Dove invierÃ i suoi s, g join?
Secondo le specifiche, questo Ã¨ ciÃ² che vedrai.
Ã il vicino che ha l'indirizzo IP piÃ¹ alto.
Questo Ã¨ fondamentalmente ciÃ² a cui si riduce.
Quindi se questo era due punto due punto due punto due e questo era due punto due punto
quattro, quindi in quel caso particolare, il join s, g sarebbe passato tramite router
quattro. Il vicino con l'indirizzo IP piÃ¹ alto quando hai ridondanza
percorsi. Questo Ã¨ anche il caso dell'albero condiviso, giusto?
Se fossi un router e avessi diversi modi per raggiungere il punto di incontro
ed avevano tutti la stessa distanza EIGRP o tutti lo stesso costo OSPF, I
sceglierebbe qualunque vicino PIM abbia l'indirizzo IP piÃ¹ alto.
Ã lÃ¬ che invierei i miei join per raggiungere il punto d'incontro.
Quindi sappiamo che s, g rimangono creati ma devono anche essere mantenuti.
Quindi questo non Ã¨ diverso.
Proprio come abbiamo parlato di come nell'albero condiviso, una volta costruito, ogni
minuto, se sono un router con un ricevitore collegato direttamente, ogni
minuto manderÃ² un'altra stella, mi unirÃ² a monte e cosÃ¬ andranno tutti
modo per mantenere quello stato aggiornato lungo il percorso.
La stessa cosa vale per il percorso piÃ¹ breve.
Ogni minuto, ogni 60 secondi, i router che hanno bisogno di mostrarci il percorso lo faranno
invia s, g si unisce a monte per mantenerlo aggiornato.
Allora quando verrÃ cancellato lo stato s, g?
Bene, se quei join periodici dal vicino a valle si interrompono, allora facciamolo
diciamo che la fonte multicast era dietro di me e io sono un router, tu sei un
router, e io sono la strada piÃ¹ breve per arrivare a quell'uomo.
Quindi in questo momento il mio elenco di interfacce in uscita punta a te.
Mi hai inviato una s, g join indicando il tuo interesse.
Ti ho inserito nell'elenco delle interfacce in uscita.
Quindi Ã¨ tua responsabilitÃ ogni minuto inviarmi s, g join per aggiornare
Questo. E se ci fosse uno switch o un hub tra noi e i tuoi?
la connessione allo switch o all'hub si interrompe?
Non lo so.
Per quanto mi riguarda, sei ancora vivo.
Bene, quindi in quel caso particolare, se i join periodici si interrompono, ancora una volta,
quel timer di 210 secondi, questo Ã¨ il numero magico, se dopo 210 secondi,
Non ricevo piÃ¹ queste iscrizioni da te, quindi le eliminerÃ²
elenco delle interfacce in uscita.
Ora, ancora una volta, in quella particolare situazione, molto probabilmente cosa accadrebbe
succede Ã¨ che direi, beh, aspetta un secondo, ho perso il mio vicino PIM, giusto?
PerchÃ© nel caso del PIM, mi mandi anche i saluti PIM ogni 30
secondi. E se ne ho persi tre, dichiaro morto un vicino.
Quindi si potrebbe supporre che se il collegamento tra te e l'interruttore funzionasse
giÃ¹, il PIM rileverebbe il vicino perduto in, abbiamo visto 105 secondi, quello
era quel timer, prima che scadesse il timer di 210 secondi.
Non lo proverÃ² adesso.
Ma voglio solo farti sapere, secondo le specifiche, se il
i join periodici si interrompono dopo 210 secondi, questo Ã¨ un criterio per la rimozione
quell'interfaccia dall'elenco delle interfacce in uscita.
Se la sorgente multicast smette di trasmettere, ancora una volta, 210 secondi dopo,
AspetterÃ², vero?
Se la fonte multicast smette di colpirmi sulla nuca, 210
secondi dopo, rimuoverÃ² le mie interfacce in uscita.
E questo accade per ogni router lungo il percorso.
Quindi in questa particolare topologia qui, se la sorgente si ferma, 210 secondi
successivamente, il router quattro rimuoverÃ la sua interfaccia e il router uno la rimuoverÃ
la sua interfaccia dall'elenco delle interfacce in uscita.
Oppure se ricevi un messaggio di eliminazione PIM.
Quindi il messaggio di prugna Ã¨ un modo per dire: ehi, non lo voglio piÃ¹.
Come in questo caso particolare, una volta che il router uno Ã¨ stato aperto con successo
sull'albero del suo percorso piÃ¹ breve, invierÃ un messaggio di prugna fino all'appuntamento
punto, dicendo: non ho piÃ¹ bisogno di questo ramo dell'albero.
Quindi possiamo effettivamente vederlo.
Non penso che ci siamo ancora concentrati sul messaggio della prugna.
Ma torniamo qui alla nostra topologia originale.
Ora penso che il router cinque a questo punto abbia probabilmente finito di inviare i suoi ping.
SÃ¬. Va bene. E se fossero trascorsi 210 secondi, cosa che probabilmente Ã¨ avvenuta, dovremmo farlo
non vedo piÃ¹ lo stato s, g in nessun router.
SÃ¬, non c'Ã¨ piÃ¹.
E' scaduto. Quindi andrÃ² avanti e lo ricomincerÃ², il ping.
E quello che cercheremo specificamente ora Ã¨ un router
due apre questo percorso, dovremmo vederlo inviare un PIM Prune al router otto.
E quindi andiamo avanti e catturiamo quella prugna solo per vedere che aspetto ha
Piace. Quindi sul router otto, voglio che zero barra uno sia la sua interfaccia in entrata.
E secondo questo, ci sarÃ zero barra due sull'interruttore.
Va bene. Quindi prepariamoci.
Vado al router cinque.
E avviamo la traccia dello snipper.
Va bene. Probabilmente Ã¨ la prugna proprio qui.
Scopriamolo. SÃ¬.
Numero di prugne uno.
Quindi, ancora una volta, il bit RP Ã¨ impostato, il che significa che sta salendo nella condivisione
albero fino al punto d'incontro.
E stiamo dicendo che sto eliminando questa fonte e questo gruppo.
Quindi Ã¨ esattamente lo stesso formato del messaggio di un'unione PIM, tranne che invece di
avendo unito, abbiamo potato.
Quindi abbiamo giÃ parlato di come le prugne PIM utilizzino lo stesso formato di PIM
join utilizzati per incoraggiare i vicini upstream a interrompere l'inoltro multicast
traffico verso di noi. Ora, perchÃ© dice incoraggiare, perchÃ© non forza il
il vicino a monte smetta di inoltrarci il traffico multicast?
Bene, ecco perchÃ©.
Se avessi questo tipo di situazione in cui ho avuto, diciamo, facciamolo e basta
Ã¨ facile, un hub. Va bene.
Diciamo che questo Ã¨ il mio RP.
Abbiamo il router uno, il router due e il router tre.
Mi collegherÃ² allo stesso hub.
Va bene. Diciamo che in questo momento entrambi questi PC, PCA e PCB, sono multicast
ricevitori. Ed entrambi ricevono esattamente lo stesso gruppo.
Sai, stanno guardando il video di presentazione del CEO proprio adesso.
Quindi il multicast sta scorrendo verso il basso.
E nel router tre abbiamo sia star che state.
E Ethernet veloce zero, zero Ã¨ nell'elenco delle interfacce in uscita.
Va bene. Se all'improvviso il destinatario A invia un messaggio IGMP, lascia perchÃ©
non Ã¨ piÃ¹ interessato a quel flusso, ciÃ² causerÃ router
uno. DirÃ , okay, eliminerÃ² questa interfaccia da
il mio elenco di interfacce in uscita.
DirÃ , oh, non ho piÃ¹ interfacce nella mia interfaccia in uscita
elenco. Il mio elenco di interfacce in uscita Ã¨ nullo.
Quindi questo lo porterÃ a dire, va bene, non ne ho piÃ¹ bisogno.
Quindi invierÃ un messaggio PMPRUN, che abbiamo appena visto nello sniffer
traccia. AndrÃ nell'hub.
Il router due lo vedrÃ .
Il router tre lo vedrÃ .
Ora, se il router tre rimuovesse immediatamente questa interfaccia, lo avremmo fatto
un problema. PerchÃ© PCB smetterebbe di ricevere lo streaming.
Ed Ã¨ ancora interessato.
Ã un ricevitore fermo e interessato.
Quindi il modo in cui funziona PEM Ã¨ quello in questo caso particolare, quando router
tre riceve questa prugna, aspetterÃ qualche secondo.
Penso che siano circa cinque secondi, anche se non citarmi su questo.
Ma sono pochi secondi.
Non Ã¨ molto tempo perchÃ© il presupposto Ã¨, ehi, se il router due
ha visto anche quella prugna, cosa farÃ ?
DirÃ : aspetta un secondo.
Ho ancora qualcuno che Ã¨ interessato.
E questo lo indurrÃ a inviare un altro join PEM.
In questo caso particolare, probabilmente saranno un join s-coma-g perchÃ©
conosce la fonte.
E cosÃ¬ questo sovrascriverÃ la prugna secca.
E cosÃ¬ manterrÃ questa interfaccia nell'elenco delle interfacce in uscita.
Ecco perchÃ© diciamo che le prugne PEM incoraggiano il vicino a monte.
PerchÃ© in questo caso particolare, il router non dirÃ , oh cavolo, mando una prugna,
ma ricevo ancora il multicast.
Beh, non c'Ã¨ davvero niente che possa fare al riguardo.
Ogni minuto continuerÃ a mandare una prugna e dire: ehi, per favore, pota
Me. E il router due lo sovrascriverÃ inviando una nota, continua cosÃ¬,
continua. Quindi Ã¨ questo che li fa scattare.
Una prugna PEM viene attivata quando ricevi una sorta di congedo
messaggio dal ricevitore o se un'interfaccia downstream va in timeout,
Giusto? Forse il ricevente se ne va, non invia mai un congedo e alla fine
tu, sai, IgMP fa scadere l'interfaccia, ciÃ² innescherebbe una prugna
anche. O se ricevi una prugna da un vicino a valle.
Quindi, in questo caso particolare, quando il router B, o quando il PCB, alla fine decide
che ha finito, non vuole piÃ¹ guardarlo.
Bene, questo farÃ sÃ¬ che il router due invii il suo messaggio di prune.
CiÃ² rimuoverÃ questa interfaccia dall'elenco delle interfacce in uscita.
E ora il router tre si rende conto che la sua lista di interfacce in uscita lo Ã¨
null, che lo indurrÃ a inviare la propria prugna PEM a monte.
Quindi questo conclude praticamente questa sezione sulla discussione sull'adesione a
albero del cammino piÃ¹ breve.
Oh, c'era un'altra cosa che vogliamo controllare prima di finire.
Lasciami tornare indietro. Vogliamo verificarlo.
Vogliamo vedere, okay, quando il multicast inizierÃ a fluire lungo il condiviso
albero, secondo la RFC, deve farlo la prima persona a effettuare il passaggio
essere il router fogliare.
Che questo router intermedio del router otto qui, perchÃ© non ha
ricevitori collegati, non Ã¨ autorizzato a eseguire il processo di commutazione.
Allora vediamo se Ã¨ effettivamente vero.
Sono sicuro che probabilmente lo Ã¨.
Ma vediamo qui.
Come lo testeremo?
Bene, ecco cosa penso che succederÃ .
Se tutto va secondo come dovrebbe andare la RFC, allora quando
router due, il router foglia riceve il primo pacchetto multicast, dovrebbe
unisciti all'albero del percorso piÃ¹ breve.
Una volta che l'albero del percorso piÃ¹ breve si apre, dovrebbe eliminare il router otto.
Il router otto dovrebbe quindi inviare una prune o un router tre.
Quindi, in un certo senso, non dovremmo mai vedere un join S, G originato dal router
otto. Dovremmo vedere che le prugne hanno avuto origine da lui, ma non dovremmo vedere
I join S, G hanno avuto origine con il suo indirizzo IP.
Quindi ecco come lo testeremo.
Passiamo semplicemente a ogni interfaccia connessa al router
otto, che Ã¨ zero due e zero tredici.
Cattureremo tutto il traffico in entrata e in uscita e vedremo se succederÃ mai
in realtÃ invia un join S, G, che non dovremmo vedere.
Va bene, quindi Ã¨ fatta.
Cancellamo lo stato MROUT, mostriamo IP, MROUT.
Ok, quindi lo stato S, G Ã¨ giÃ scaduto.
Andiamo all'interruttore.
Quindi in questo momento stiamo monitorando lo zero due.
Vogliamo aggiungere zero tredici a quella lista.
Va bene, torniamo al router cinque.
Avvia la traccia del nostro snipper.
Ok, a questo punto non vedo il multicast passare attraverso il router
otto piÃ¹, perchÃ© in questo momento l'unica cosa che sto guardando sono le interfacce
connesso al router otto e non vedo alcun multicast in corso
da lÃ¬. Si Ã¨ fermato proprio qui.
Quindi vediamo qui otto due otto due.
Questo Ã¨ il router due otto quattro otto otto.
Questo Ã¨ il router otto otto quattro otto otto.
Ok, allora cosa ha inviato il router otto proprio lÃ¬?
Router otto otto quattro otto otto.
Ha mandato una prugna.
Ok, quindi questo Ã¨ lui che ha mandato una prugna sull'albero condiviso, e l'ha fatto
in risposta alla prugna secca che ha ricevuto.
Quindi questa Ã¨ molto probabilmente la prugna secca che ha ricevuto.
Quindi questo Ã¨ sÃ¬, quindi questa Ã¨ la prugna del router due che Ã¨ connesso
al nostro ricevitore che ha detto, ehi, guarda, vicino otto due otto otto.
Non ho piÃ¹ bisogno di te.
Potiamo quell'albero condiviso tra me e te.
E il router otto ha inoltrato lui stesso quella prugna al punto d'incontro.
Quindi, come previsto, non vediamo alcun messaggio di join dal router otto.
Qui si unisce all'auto RP, quindi non conta.
Quindi, abbastanza sicuro, ciÃ² conferma ciÃ² che dice la RFC, che solo i router foglia
oppure i router last hop possono unirsi all'albero del percorso piÃ¹ breve.