1
00:00:08,320 --> 00:00:11,100
 Va bene, allora vediamo qui.

2
00:00:11,100 --> 00:00:15,700
 Quindi vogliamo vedere il
 processo di registrazione.

3
00:00:15,700 --> 00:00:22,900
 Il modo piÃ¹ semplice per creare traffico multicast
 Ã¨ semplicemente eseguire un multicast

4
00:00:22,900 --> 00:00:25,160
 ping. E in realtÃ  questo sarÃ  facile.

5
00:00:25,160 --> 00:00:31,140
 Il motivo per cui esitavo Ã¨ perchÃ©,
 ad esempio, se facessi un multicast

6
00:00:31,140 --> 00:00:37,800
 ping dal router 4, quando si avvia
 un ping multicast da un router,

7
00:00:37,800 --> 00:00:43,400
 invierÃ  effettivamente quel pacchetto multicast,
 quel pacchetto ICMP multicast

8
00:00:43,400 --> 00:00:48,700
 su ogni singola interfaccia
 che ha PIM abilitato.

9
00:00:48,700 --> 00:00:51,420
 Voglio dire, non si prende nemmeno la briga di
 controllare lo stato della rotta M o altro.

10
00:00:51,420 --> 00:00:54,160
 Lo copia e lo invia ogni
 singolo pacchetto.

11
00:00:54,160 --> 00:00:55,460
 E non lo volevo.

12
00:00:55,460 --> 00:00:57,740
 Ma in questo caso non devo preoccuparmi
 perchÃ© sul router 5, he

13
00:00:57,740 --> 00:00:59,680
 ha comunque solo un'interfaccia.

14
00:00:59,680 --> 00:01:02,340
 Quindi vediamo qui.

15
00:01:02,340 --> 00:01:06,300
 Vogliamo catturare il...

16
00:01:06,300 --> 00:01:10,880
 Quindi questo sarÃ  il
 pacchetto multicast.

17
00:01:10,880 --> 00:01:15,540
 VerrÃ  giÃ¹ da questa parte.

18
00:01:15,540 --> 00:01:20,580
 E vogliamo vedere quel pacchetto multicast
 cosÃ¬ come Ã¨ incapsulato in un PIM

19
00:01:20,580 --> 00:01:33,020
 Registrati. E poi vogliamo anche vedere
 non appena l'RP lo otterrÃ , noi

20
00:01:33,020 --> 00:01:43,240
 voglio vederlo inviare un join PIM-S-G
 per aprire il suo percorso piÃ¹ breve.

21
00:01:43,240 --> 00:01:48,100
 Quindi vedremo il multicast stesso scorrere
 verso il basso nel suo nativo

22
00:01:48,100 --> 00:01:55,740
 modulo. E infine, vogliamo vedere
 l'RP una volta ottenuto, inviando

23
00:01:55,740 --> 00:01:57,680
 un arresto del registro PIM.

24
00:01:57,680 --> 00:02:02,920
 PerchÃ© questo sarÃ  il processo.

25
00:02:02,920 --> 00:02:06,500
 Quindi, per farlo, vediamo qui.

26
00:02:06,500 --> 00:02:13,260
 PerchÃ© non catturo semplicemente tutto ciÃ²
 che entra ed esce dal router 3 velocemente

27
00:02:13,260 --> 00:02:22,740
 ethernet 00. Quindi il router 3 Ã¨ veloce
 ethernet 00 Ã¨ la porta 0 barra 5 su

28
00:02:22,740 --> 00:02:39,740
 interruttore. Va bene, sÃ¬, 0 barra 5.

29
00:02:39,740 --> 00:02:41,140
 Ok, quindi dovremmo essere pronti.

30
00:02:41,140 --> 00:02:45,080
 Andiamo ora alla fonte.

31
00:02:45,080 --> 00:02:50,440
 E penso che sia 999 quello
 che sto usando.

32
00:02:50,440 --> 00:02:56,060
 E lo ripeterÃ² 100 volte solo
 per continuare per un po'.

33
00:02:56,060 --> 00:03:05,120
 E iniziamo la traccia dello sniffer.

34
00:03:05,120 --> 00:03:07,920
 Ok, ci siamo.

35
00:03:07,920 --> 00:03:11,240
 Questo bastava.

36
00:03:11,240 --> 00:03:14,600
 Ok, ecco il registro.

37
00:03:14,600 --> 00:03:21,020
 Quindi in realtÃ  non lo vediamo, perchÃ©
 sto solo catturando, andiamo

38
00:03:21,020 --> 00:03:25,280
 torniamo a questo. PerchÃ© sto solo acquisendo
 dati in entrata e in uscita

39
00:03:25,280 --> 00:03:28,620
 00, in realtÃ  non abbiamo visto il multicast
 nativo quando Ã¨ arrivato al router

40
00:03:28,620 --> 00:03:31,880
 4. Ma vediamo il messaggio di registro.

41
00:03:31,880 --> 00:03:35,440
 Quindi eccolo qui, registro PIM.

42
00:03:35,440 --> 00:03:41,720
 Quindi questo Ã¨ l'indirizzo IP 4545.

43
00:03:41,720 --> 00:03:44,460
 Controlliamo qui.

44
00:03:44,460 --> 00:03:47,780
 Dovrebbe essere il router 4 a
 registrare e non il router 5.

45
00:03:47,780 --> 00:03:52,660
 Fammi solo controllare il router
 5 qui per un secondo.

46
00:03:52,660 --> 00:04:00,580
 Bene, vediamo, questo Ã¨ interessante,
 ma c'Ã¨ un modo semplice per verificare

47
00:04:00,580 --> 00:04:05,200
 Questo. Quindi l'indirizzo di origine proviene
 effettivamente dalla fonte stessa

48
00:04:05,200 --> 00:04:12,680
 4545. Ma viene davvero da lui o
 Ã¨ stato il router 4 a inserirlo

49
00:04:12,680 --> 00:04:16,900
 lÃ¬ dentro? Bene, possiamo verificarlo controllando
 l'indirizzo MAC di origine di

50
00:04:16,900 --> 00:04:21,060
 questo fotogramma per vedere
 da chi proviene veramente.

51
00:04:21,060 --> 00:04:28,300
 Quindi l'indirizzo MAC di origine
 proveniva da 8C B6.

52
00:04:28,300 --> 00:04:43,140
 8C B6. Quindi proveniva davvero
 da FastEthernet01 e R5?

53
00:04:43,140 --> 00:04:48,440
 No, non Ã¨ stato cosÃ¬ perchÃ© Ã¨ 8E0051.

54
00:04:48,440 --> 00:04:50,840
 Quindi se andiamo al router 4.

55
00:04:50,840 --> 00:05:02,900
 Spiacenti, non mostra esecuzione,
 mostra interfaccia.

56
00:05:02,900 --> 00:05:05,520
 FastEthernet00.34.

57
00:05:05,520 --> 00:05:09,500
 Eccoci qua. 8C B6.

58
00:05:09,500 --> 00:05:12,120
 Quindi Ã¨ interessante, guarda questo.

59
00:05:12,120 --> 00:05:18,180
 Quindi, quando il multicast nativo raggiunge
 il router 4, quando lo incapsula in

60
00:05:18,180 --> 00:05:22,480
 un messaggio di registrazione,
 aspetta un secondo.

61
00:05:22,480 --> 00:05:25,980
 Penso che questa sia una stranezza in realtÃ ,
 penso di ricordare che questo Ã¨ a

62
00:05:25,980 --> 00:05:30,720
 stranezza dello squalo metallico,
 non proprio del cecchino.

63
00:05:30,720 --> 00:05:33,280
 SÃ¬, eccoci qui.

64
00:05:33,280 --> 00:05:35,780
 Ok, non sono sicuro del motivo per cui
 allo squalo del filo non piace questo.

65
00:05:35,780 --> 00:05:39,600
 QuassÃ¹ nella finestra principale,
 dice che arriva dalla 4.5.

66
00:05:39,600 --> 00:05:46,060
 Se guardi effettivamente nel corpo, qui
 nell'intestazione IP, sta arrivando

67
00:05:46,060 --> 00:05:52,780
 dal router 4. Quindi non sono sicuro del
 motivo della discrepanza qui tra come it

68
00:05:52,780 --> 00:05:57,020
 lo visualizza. Ma quindi ecco
 la mia intestazione IP.

69
00:05:57,020 --> 00:06:03,100
 Quindi viene dal router 4, va
 al punto d'incontro, router 3,

70
00:06:03,100 --> 00:06:10,220
 e poi dietro l'intestazione IP
 c'Ã¨ la nostra intestazione PIM.

71
00:06:10,220 --> 00:06:17,740
 Quindi digita il numero 1, che
 Ã¨ un pacchetto di registri.

72
00:06:17,740 --> 00:06:25,600
 E poi potete vedere qui che ci sono
 solo un paio di bandiere, e poi ecco

73
00:06:25,600 --> 00:06:31,360
 in realtÃ  il pacchetto multicast
 al suo interno.

74
00:06:31,360 --> 00:06:40,540
 Provenendo dalla fonte, andando
 al gruppo e solo un paio di cose

75
00:06:40,540 --> 00:06:42,480
 su questo nel caso in cui sei curioso.

76
00:06:42,480 --> 00:06:45,240
 ParlerÃ² del registro nullo come l'ultima
 cosa in questo particolare

77
00:06:45,240 --> 00:06:51,840
 video. Ma questa cosa qui chiamata
 confine, di cosa si tratta?

78
00:06:51,840 --> 00:06:59,400
 Dice di no. C'Ã¨ una funzionalitÃ  che puoi
 utilizzare in modalitÃ  sparsa PIM chiamata

79
00:06:59,400 --> 00:07:02,920
 un router di confine o un
 router di confine PIM.

80
00:07:02,920 --> 00:07:07,120
 CioÃ¨, e onestamente non sono sicuro della frequenza
 con cui viene utilizzato nel file

81
00:07:07,120 --> 00:07:12,360
 mondo reale, ma ad esempio, se avessi
 un router, lo farebbe da un lato

82
00:07:12,360 --> 00:07:20,420
 qualcosa che non Ã¨ PIM.

83
00:07:20,420 --> 00:07:23,560
 Quindi stiamo realizzando un pezzo ed eseguendo
 il PIM sull'altra interfaccia.

84
00:07:23,560 --> 00:07:25,960
 E vogliamo che il multicast fluisca.

85
00:07:25,960 --> 00:07:29,260
 Sarebbe considerato un
 router di confine PIM.

86
00:07:29,260 --> 00:07:33,180
 In quel caso particolare, se quel router
 ha inviato un registro, quel bit

87
00:07:33,180 --> 00:07:37,800
 lÃ¬, quel bit flag, verrebbe impostato
 su 1, dicendo che sÃ¬, Ã¨ un confine

88
00:07:37,800 --> 00:07:41,440
 router. Ma non stiamo facendo quel genere
 di cose strane qui, cosÃ¬ dice

89
00:07:41,440 --> 00:07:43,740
 no, non Ã¨ un router di frontiera.

90
00:07:43,740 --> 00:07:51,420
 Quindi c'Ã¨ il nostro registro, un'intestazione PIM
 di base piuttosto semplice, e poi semplicemente

91
00:07:51,420 --> 00:07:53,700
 il multicast effettivo al suo interno.

92
00:07:53,700 --> 00:08:00,140
 E poi secondo la nostra lavagna, abbiamo
 detto una volta che Ã¨ venuto giÃ¹, il

93
00:08:00,140 --> 00:08:04,420
 il punto d'incontro dovrebbe quindi tentare di
 aprire il suo albero del percorso piÃ¹ breve

94
00:08:04,420 --> 00:08:13,000
 inviando un join S, G.

95
00:08:13,000 --> 00:08:16,860
 Quindi, vediamo qui.

96
00:08:16,860 --> 00:08:23,580
 Probabilmente Ã¨ proprio questo qui,
 si unisce PIM, vediamo qui.

97
00:08:23,580 --> 00:08:30,320
 Sta arrivando, l'indirizzo di origine proviene
 dal nostro punto d'incontro, 343,

98
00:08:30,320 --> 00:08:31,380
 quello Ã¨ il router 3.

99
00:08:31,380 --> 00:08:40,140
 VerrÃ  inviato all'indirizzo PIM 2240013.

100
00:08:40,140 --> 00:08:44,100
 Digitare il codice 3 per partecipare.

101
00:08:44,100 --> 00:08:49,640
 Ora nota, cosa lo rende diverso
 da una stella, unisciti?

102
00:08:49,640 --> 00:08:51,400
 Beh, un paio di cose.

103
00:08:51,400 --> 00:08:54,180
 Numero uno, numero di join uno.

104
00:08:54,180 --> 00:08:58,140
 Ricordi che abbiamo visto queste
 bandiere qui di SW e R?

105
00:08:58,140 --> 00:09:00,580
 Ebbene, questa volta non lo vediamo.

106
00:09:00,580 --> 00:09:07,940
 La R significava che il bit RP era impostato, il che
 significa che era necessario questo particolare join

107
00:09:07,940 --> 00:09:09,660
 salire sull'albero condiviso.

108
00:09:09,660 --> 00:09:12,300
 La destinazione finale era
 il punto d'incontro.

109
00:09:12,300 --> 00:09:14,600
 Beh, non lo vediamo qui.

110
00:09:14,600 --> 00:09:17,860
 Il bit W Ã¨ stato impostato
 come bit jolly.

111
00:09:17,860 --> 00:09:22,220
 Il carattere jolly significava che, okay,
 quando guardi questo indirizzo, questo

112
00:09:22,220 --> 00:09:24,600
 indirizzo Ã¨ l'indirizzo
 del punto d'incontro.

113
00:09:24,600 --> 00:09:27,120
 Bene, qui non lo vediamo.

114
00:09:27,120 --> 00:09:31,620
 Il bit jolly non Ã¨ impostato, il che significa
 che questo Ã¨ effettivamente l'indirizzo

115
00:09:31,620 --> 00:09:38,400
 della fonte. Quindi, sembra una specie di
 stella, unisciti, ma solo fino a quando

116
00:09:38,400 --> 00:09:41,800
 scavi nelle viscere e vedi quali bandiere
 ci sono qui o quali bandiere

117
00:09:41,800 --> 00:09:48,160
 non sono qui, puoi effettivamente dire
 se Ã¨ una stella o una S, unisciti.

118
00:09:48,160 --> 00:09:50,900
 E questo caso Ã¨ una S, unisciti.

119
00:09:50,900 --> 00:09:54,380
 Quindi dice, okay, vicino a monte,
 quindi questo Ã¨ il router quattro.

120
00:09:54,380 --> 00:10:00,780
 Dice, questo va a te, e sto cercando
 di unirmi a questa fonte e

121
00:10:00,780 --> 00:10:12,420
 questo gruppo. Ok, quindi
 c'Ã¨ la S, iscriviti.

122
00:10:12,420 --> 00:10:19,200
 E poi una volta ricevuta la S, join,
 avrebbe dovuto inserire questo sub

123
00:10:19,200 --> 00:10:24,240
 -interfaccia nell'elenco delle interfacce
 in uscita del router quattro.

124
00:10:24,240 --> 00:10:30,820
 E poi il multicast nativo avrebbe dovuto essere
 disattivato, e avremmo dovuto farlo

125
00:10:30,820 --> 00:10:35,220
 ne ho ricevuto due copie, una in una busta
 di registro e una in quella nativa

126
00:10:35,220 --> 00:10:36,340
 multicast stesso.

127
00:10:36,340 --> 00:10:37,820
 Quindi vediamo se l'abbiamo visto.

128
00:10:37,820 --> 00:10:48,440
 Quindi ecco il nostro join, e sembra,
 okay, quindi proprio qui, ecco il

129
00:10:48,440 --> 00:10:52,240
 multicast nativo, nota
 che non c'Ã¨ PIM qui.

130
00:10:52,240 --> 00:10:57,320
 La sorgente Ã¨ in realtÃ  la sorgente, ecco
 il multicast nativo e poi a destra

131
00:10:57,320 --> 00:11:05,600
 dietro c'Ã¨ un registro PIM.

132
00:11:05,600 --> 00:11:09,040
 Ed ecco una domanda interessante: sono
 effettivamente lo stesso pacchetto

133
00:11:09,040 --> 00:11:14,580
 copiato? Bene, vediamo qui, nell'attuale
 multicast nativo, nell'IP

134
00:11:14,580 --> 00:11:19,960
 intestazione, abbiamo un'identificazione
 di 0, 0, 0, 1.

135
00:11:19,960 --> 00:11:24,640
 Ricorda, normalmente ogni singolo pacchetto
 IP ha un'identificazione univoca

136
00:11:24,640 --> 00:11:28,880
 campo. Vediamo qui, che mi dici
 del pacchetto di registrazione?

137
00:11:28,880 --> 00:11:33,740
 Ha esattamente lo stesso ID, quindi sÃ¬, questi
 sono duplicati dello stesso pacchetto.

138
00:11:33,740 --> 00:11:44,880
 Va bene, quindi una volta visto questo,
 vediamo quaggiÃ¹, il router tre,

139
00:11:44,880 --> 00:11:50,440
 che Ã¨ l'RP che dice stop ai registri,
 dicendo che non voglio piÃ¹ i registri.

140
00:11:50,440 --> 00:11:57,280
 Quindi proprio qui nel corpo del PIM, digita
 il codice due, registro stop, e lui dice

141
00:11:57,280 --> 00:12:01,060
 Mi fermo per questa fonte
 e questo gruppo.

142
00:12:01,060 --> 00:12:09,840
 Ora c'era un altro campo nel registro
 che in un certo senso ho saltato

143
00:12:09,840 --> 00:12:19,940
 un flag di cui non ho parlato, che era
 questo proprio qui, il registro nullo

144
00:12:19,940 --> 00:12:21,320
 bandiera, cos'Ã¨?

145
00:12:21,320 --> 00:12:26,680
 In questo caso particolare, il registro nullo
 Ã¨ impostato su no, Ã¨ disattivato, ma

146
00:12:26,680 --> 00:12:32,880
 quando sarÃ  attivo e perchÃ©
 dovremmo usarlo?

147
00:12:32,880 --> 00:12:42,260
 Quindi, diciamo, disegniamo qualcosa qui per
 un momento, e in realtÃ  possiamo farlo

148
00:12:42,260 --> 00:12:47,280
 usa questo come esempio.

149
00:12:47,280 --> 00:12:53,780
 Diciamo che il nostro ricevitore era
 quaggiÃ¹, e inizialmente il multicast

150
00:12:53,780 --> 00:12:58,440
 il flusso scorreva attraverso l'albero condiviso
 attraverso l'RP, ma lo sappiamo

151
00:12:58,440 --> 00:13:00,800
 entro un breve lasso di tempo
 e lo esamineremo nel

152
00:13:00,800 --> 00:13:15,400
 Nella prossima sezione passeremo
 dall'albero condiviso a quello

153
00:13:15,400 --> 00:13:22,940
 il traffico non va piÃ¹ all'RP, questo
 Ã¨ stato, ops, non quello, questo

154
00:13:22,940 --> 00:13:29,640
 l'interfaccia Ã¨ stata eliminata, liberiamoci
 di tutta questa roba e

155
00:13:29,640 --> 00:13:36,100
 ora il traffico scorre nella sua forma nativa pura
 in questa direzione, lungo la via piÃ¹ breve

156
00:13:36,100 --> 00:13:38,580
 albero del percorso verso il ricevitore.

157
00:13:38,580 --> 00:13:43,300
 Ok, quindi il multicast va,
 va, va, va bene, va bene

158
00:13:43,300 --> 00:13:50,280
 andando bene. Ma cosa succede se 10,
 15, 20 minuti dopo accade questo?

159
00:13:50,280 --> 00:13:57,600
 Abbiamo un altro ricevitore che si unisce
 alla nostra topologia e vuole l'esatto

160
00:13:57,600 --> 00:14:02,620
 stesso flusso, quindi invia un
 rapporto di adesione all'IGMP.

161
00:14:02,620 --> 00:14:13,620
 CiÃ² dÃ  il via a una unione PIM stella-coma-G,
 che crea lo stato stella-coma-G

162
00:14:13,620 --> 00:14:19,980
 nel RP, e il RP sta semplicemente seduto
 qui, aspettando, aspettando e aspettando.

163
00:14:19,980 --> 00:14:23,500
 Dopotutto il router Z non ha motivo di
 inoltrare questo traffico multicast

164
00:14:23,500 --> 00:14:27,300
 all'RP, giusto, l'RP ha eliminato
 questa interfaccia.

165
00:14:27,300 --> 00:14:32,140
 Una volta che il traffico inizia a scendere lungo
 l'albero del percorso piÃ¹ breve, riceviamo

166
00:14:32,140 --> 00:14:36,240
 alcune prugne in questo modo, e all'RP Ã¨ stato
 detto, ehi, non abbiamo piÃ¹ bisogno di te,

167
00:14:36,240 --> 00:14:39,040
 non abbiamo bisogno del tuo traffico.

168
00:14:39,040 --> 00:14:44,020
 E quando l'RP lo ha sentito, ha detto, okay,
 immagino di non averne piÃ¹ bisogno,

169
00:14:44,020 --> 00:14:48,100
 nessun altro lo vuole da me, quindi l'RP
 ha eliminato questo collegamento.

170
00:14:48,100 --> 00:14:50,760
 Quindi Ã¨ successo molto tempo fa.

171
00:14:50,760 --> 00:14:57,300
 Ora qualcuno chiede nuovamente all'RP
 questo traffico, ma non ottiene

172
00:14:57,300 --> 00:15:03,700
 Esso. Ã qui che puÃ² entrare
 in gioco il registro nullo.

173
00:15:03,700 --> 00:15:10,640
 Parliamo quindi del registro nullo.

174
00:15:10,640 --> 00:15:15,300
 Quindi sappiamo che dopo un po' l'RP
 potrebbe dimenticarsi di quel flusso.

175
00:15:15,300 --> 00:15:17,160
 Originariamente lo ha attraversato.

176
00:15:17,160 --> 00:15:21,280
 Lo elimina perchÃ© non ne ha piÃ¹
 bisogno e se ne dimentica

177
00:15:21,280 --> 00:15:31,420
 Esso. Quindi quello che succederÃ 
 qui Ã¨ questo, il router connesso

178
00:15:31,420 --> 00:15:35,580
 alla fonte, il router 4 dice, beh,
 ho inviato questo multicast per

179
00:15:35,580 --> 00:15:40,500
 un po. C'Ã¨ la possibilitÃ  che
 forse l'RP ne abbia bisogno.

180
00:15:40,500 --> 00:15:44,140
 Ehi, forse qualcun altro vuole
 ricevere questo traffico.

181
00:15:44,140 --> 00:15:47,880
 Forse dovrei far sapere alla
 RP che Ã¨ ancora in corso.

182
00:15:47,880 --> 00:15:56,660
 Bene, potremmo prendere il prossimo
 pacchetto e registrarlo con l'RP.

183
00:15:56,660 --> 00:15:58,460
 Funzionerebbe.

184
00:15:58,460 --> 00:16:02,180
 Ma invece i desideri del PIM dicevano: beh,
 non voglio continuare a preoccuparmi

185
00:16:02,180 --> 00:16:05,160
 l'RP con questa registrazione,
 perchÃ© forse non ha nessuno.

186
00:16:05,160 --> 00:16:09,560
 Forse nessuno che lui conosca
 vuole davvero questo traffico.

187
00:16:09,560 --> 00:16:17,820
 Quindi, invece, ciÃ² che accade Ã¨ che ogni pochi secondi
 il router 4 invia quello che viene chiamato

188
00:16:17,820 --> 00:16:22,800
 un registro nullo al punto d'incontro.

189
00:16:22,800 --> 00:16:25,480
 Cos'Ã¨ un registro nullo?

190
00:16:25,480 --> 00:16:29,580
 Fondamentalmente assomiglia esattamente ad un
 normale pacchetto di registri, ma non Ã¨ cosÃ¬

191
00:16:29,580 --> 00:16:32,080
 contenere dati multicast al suo interno.

192
00:16:32,080 --> 00:16:39,140
 Quindi, se torniamo alla traccia dello
 sniffer, un registro nullo direbbe tipo

193
00:16:39,140 --> 00:16:51,680
 1 registro, e qui ci sarebbero
 informazioni sulla fonte e

194
00:16:51,680 --> 00:16:54,860
 il gruppo. Ma non ci
 sarebbe nessun corpo.

195
00:16:54,860 --> 00:16:56,980
 Non ci sarebbero dati multicast
 al suo interno.

196
00:16:56,980 --> 00:16:58,980
 Sarebbe un pacchetto molto piÃ¹ piccolo.

197
00:16:58,980 --> 00:17:02,680
 E il flag di registro nullo
 verrebbe impostato su 1.

198
00:17:02,680 --> 00:17:08,380
 E questo Ã¨ il modo in cui questo router
 qui potrebbe dire, ehi, RP vuole solo

199
00:17:08,380 --> 00:17:11,720
 che tu lo sappia, conosco
 ancora questo flusso.

200
00:17:11,720 --> 00:17:13,540
 Mi sta ancora attraversando.

201
00:17:13,540 --> 00:17:17,420
 Quindi se lo vuoi, faresti
 meglio a dirmelo.

202
00:17:17,420 --> 00:17:21,300
 E poi una volta che il router ha ottenuto, una volta
 che l'RP ha ottenuto quel registro nullo, lo Ã¨

203
00:17:21,300 --> 00:17:22,520
 dicendo: oh, bene, bene.

204
00:17:22,520 --> 00:17:25,460
 Aspettavo di sapere di quel traffico,
 perchÃ© qualcuno me lo ha chiesto

205
00:17:25,460 --> 00:17:30,380
 per questo. Quindi ora lâRP potrebbe ancora una
 volta inviare un join S-comaG per aprirsi

206
00:17:30,380 --> 00:17:36,520
 questo percorso e il traffico potrebbe iniziare
 a scorrere in questa direzione.

207
00:17:36,520 --> 00:17:40,880
 Ecco cos'Ã¨ un registro nullo.

208
00:17:40,880 --> 00:17:43,680
 E questi vengono inviati
 ogni cinque secondi.

209
00:17:43,680 --> 00:17:47,120
 Questo Ã¨ chiamato tempo di sonda.

210
00:17:47,120 --> 00:17:51,680
 Quindi ogni cinque secondi, il router
 piÃ¹ vicino alla fonte, se il

211
00:17:51,680 --> 00:17:55,200
 source Ã¨ ancora in funzione, se sta ancora
 emettendo il multicast, lo faremo

212
00:17:55,200 --> 00:17:58,380
 invia ogni cinque secondi questi registri
 nulli all'RP, solo per ricordarlo

213
00:17:58,380 --> 00:18:01,720
 l'RP che questo traffico esiste.

214
00:18:01,720 --> 00:18:06,480
 PerchÃ© forse negli ultimi cinque secondi
 un nuovo ricevitore si Ã¨ unito al

215
00:18:06,480 --> 00:18:09,440
 RP, e forse RP vuole di
 nuovo quel traffico.
