1
00:00:08,860 --> 00:00:12,380
 Ok, então o Mac multicast, lembre-se
 que estamos falando de um destino

2
00:00:12,380 --> 00:00:18,460
 Endereço Mac, é parcialmente derivado
 do endereço IP multicast real

3
00:00:18,460 --> 00:00:20,840
 que fica acima dele na camada de rede.

4
00:00:20,840 --> 00:00:26,520
 Portanto, esses são os dois OUIs reservados
 que você deve procurar para multicast.

5
00:00:26,520 --> 00:00:30,160
 Se você alguma vez vir um quadro Ethernet
 indo para um destino começando

6
00:00:30,160 --> 00:00:36,780
 com 01005E, isso deve fazer você dizer
 aha, esse quadro está carregando

7
00:00:36,780 --> 00:00:40,520
 um pacote multicast IP versão 4.

8
00:00:40,520 --> 00:00:46,280
 Então esse é o OUI reservado
 para dados multicast IPv4.

9
00:00:46,280 --> 00:00:52,220
 E então, se você vir alguma coisa indo
 para 33333, isso está reservado para

10
00:00:52,220 --> 00:00:55,260
 Multicast IPv6.

11
00:00:55,260 --> 00:00:59,180
 Ok, então vamos falar um pouco
 sobre como derivamos as coisas.

12
00:00:59,180 --> 00:01:00,880
 Em primeiro lugar, vamos
 começar com o IPv6.

13
00:01:00,880 --> 00:01:04,360
 IPv6 é muito fácil e depois
 voltarei para IPv4.

14
00:01:04,360 --> 00:01:09,640
 Digamos que meu endereço IPv6
 multicast, vou inventar algo

15
00:01:09,640 --> 00:01:19,340
 aqui. Digamos que estava indo para FF0E,
 então este é um multicast global, e

16
00:01:19,340 --> 00:01:36,300
 digamos apenas 11111 e depois AAAA,
 BBBB, CCC, vamos ver, 1, 2, 3, 4,

17
00:01:36,300 --> 00:01:39,060
 5, preciso de mais três.

18
00:01:39,060 --> 00:01:47,780
 E então 2222, 777, 1, 2, 3, 4, 5, 6, 7,
 então faremos apenas o último octeto,

19
00:01:47,780 --> 00:01:53,700
 meio que execute DDD.

20
00:01:53,700 --> 00:02:00,760
 Ok, tudo o que faremos é quando
 a fonte multicast gerar este

21
00:02:00,760 --> 00:02:06,380
 endereço como o endereço de destino na camada
 três, depois disso, quando ele estiver

22
00:02:06,380 --> 00:02:11,080
 criando seu quadro Ethernet, tudo o
 que ele fará é pegar os últimos 32

23
00:02:11,080 --> 00:02:19,100
 bits, que neste caso é 777 e
 DDDD, e ele vai corrigir isso

24
00:02:19,100 --> 00:02:21,180
 aqui, onde estão esses X.

25
00:02:21,180 --> 00:02:26,380
 Portanto, na camada dois, o quadro Ethernet
 será destinado a 333 dois pontos 777

26
00:02:26,380 --> 00:02:32,020
 dois pontos DDDD. Então
 isso é muito fácil.

27
00:02:32,020 --> 00:02:36,400
 Lembre-se de que os últimos 32 bits do
 endereço multicast IPv6 são diretamente

28
00:02:36,400 --> 00:02:42,420
 mapeado para os últimos 32 bits do endereço
 MAC de destino do quadro Ethernet.

29
00:02:42,420 --> 00:02:47,400
 Agora, no mundo do IPv4, mapear
 isso é meio que um pesadelo.

30
00:02:47,400 --> 00:02:50,580
 Então tenha paciência comigo aqui, se você
 ainda não tomou seu café, você pode querer

31
00:02:50,580 --> 00:02:54,660
 dar um grande gole neste momento, porque
 isso normalmente faz com que as pessoas

32
00:02:54,660 --> 00:02:55,620
 os olhos ficam vidrados.

33
00:02:55,620 --> 00:02:58,960
 Mas vamos seguir em frente e analisar
 isso porque acho que você deveria

34
00:02:58,960 --> 00:03:08,780
 saber disso. Então, em primeiro lugar, conhecemos
 meu endereço MAC multicast na camada

35
00:03:08,780 --> 00:03:21,920
 dois é 01005E. E agora você pode
 pensar, ok, bem, isso é metade do

36
00:03:21,920 --> 00:03:25,200
 endereço, certo? Um endereço
 MAC tem 48 bits.

37
00:03:25,200 --> 00:03:30,380
 Isso é metade. Então você pode pensar,
 ok, ainda tenho 24 bits para mapear.

38
00:03:30,380 --> 00:03:32,720
 Bem, não exatamente.

39
00:03:32,720 --> 00:03:37,640
 Se eu converter isso em binário
 para o resto, apenas parte, o

40
00:03:37,640 --> 00:03:42,380
 o próximo bit deve ser zero.

41
00:03:42,380 --> 00:03:52,620
 E então você tem 12345678
 dois pontos 12345678.

42
00:03:52,620 --> 00:03:54,380
 Eu simplesmente farei isso.

43
00:03:54,380 --> 00:04:00,580
 Dois pontos 12345678. Estou ficando
 sem espaço, mas você entendeu.

44
00:04:00,580 --> 00:04:05,580
 Portanto, dos meus 24 bits restantes,
 na verdade só tenho 23 bits.

45
00:04:05,580 --> 00:04:09,520
 Esse aqui tem que ser zerado.

46
00:04:09,520 --> 00:04:12,320
 E se você estiver olhando para
 isso e se perguntando o quê?

47
00:04:12,320 --> 00:04:14,180
 Bem, isso não faz sentido.

48
00:04:14,180 --> 00:04:16,000
 Vou te dizer uma coisa, há
 uma história interessante.

49
00:04:16,000 --> 00:04:18,640
 Não vou entrar na história, mas é isso
 que você deveria pesquisar no Google

50
00:04:18,640 --> 00:04:21,980
 para descobrir por que eles
 acabaram fazendo assim?

51
00:04:21,980 --> 00:04:24,800
 Pesquise isso no Google.
 Google o nome Steve.

52
00:04:24,800 --> 00:04:34,380
 Sobrenome, Deering.

53
00:04:34,380 --> 00:04:36,880
 Mac multicast. Google isso.

54
00:04:36,880 --> 00:04:39,780
 Steve Deering Multicast Mac.

55
00:04:39,780 --> 00:04:42,480
 E você poderá encontrar uma história
 interessante sobre Steve Deering.

56
00:04:42,480 --> 00:04:45,040
 um dos pioneiros originais do multicast.

57
00:04:45,040 --> 00:04:47,160
 Ele fez grande parte do
 trabalho inicial nisso.

58
00:04:47,160 --> 00:04:49,880
 E você encontrará uma história interessante
 sobre quando ele era estudante de graduação,

59
00:04:49,880 --> 00:04:54,720
 uma pequena interação que ele teve com seu
 professor que tinha a ver com dinheiro,

60
00:04:54,720 --> 00:04:59,100
 e acabou com uma coisa estranha
 aqui, com apenas 23 bits sendo

61
00:04:59,100 --> 00:05:04,440
 disponível. Ok, então como mapeamos
 o endereço IP multicast?

62
00:05:04,440 --> 00:05:09,700
 Bem, se você puder manter isso em
 mente, agora deve ser bem fácil.

63
00:05:09,700 --> 00:05:14,420
 Basta pegar os últimos 23 bits do endereço
 IP multicast e mapeá-los aqui.

64
00:05:14,420 --> 00:05:20,180
 Digamos que meu endereço
 IP multicast seja 239.

65
00:05:20,180 --> 00:05:29,420
 Bem, não importa qual seja o primeiro
 octeto, seja 224 até 239, é sempre

66
00:05:29,420 --> 00:05:31,660
 vou mapear até 5e, certo?

67
00:05:31,660 --> 00:05:34,400
 Como esse octeto está meio cancelado,
 sempre se tornará

68
00:05:34,400 --> 00:05:39,600
 5e. E agora digamos que eu tenha
 um fluxo multicast de 239.

69
00:05:39,600 --> 00:05:43,300
 vamos apenas tornar isso mais fácil.

70
00:05:43,300 --> 00:05:48,360
 1.1.1. Esse é o meu endereço
 IP multicast.

71
00:05:48,360 --> 00:05:54,480
 Bem, o endereço MAC multicast resultante
 seria 01005e, e esses bits

72
00:05:54,480 --> 00:05:56,040
 seria mapeado aqui.

73
00:05:56,040 --> 00:06:01,620
 Então seria 01005e, 1111.

74
00:06:01,620 --> 00:06:06,860
 Bem, e se eu tivesse 225.1.1?

75
00:06:06,860 --> 00:06:11,320
 Seria exatamente a mesma coisa.

76
00:06:11,320 --> 00:06:14,400
 0111, todos eles seriam mapeados
 para o mesmo MAC multicast.

77
00:06:14,400 --> 00:06:15,700
 Então, vamos somar isso por um segundo.

78
00:06:15,700 --> 00:06:21,860
 Se você fizer algumas contas rápidas, se
 começarmos em 224 e subirmos para 239,

79
00:06:21,860 --> 00:06:25,440
 quantos números únicos são esses?

80
00:06:25,440 --> 00:06:30,440
 Vou te dizer agora, são um
 total de 16 números únicos.

81
00:06:30,440 --> 00:06:35,100
 De 224 a 239 são 16 combinações de bytes.

82
00:06:35,100 --> 00:06:42,440
 Então, de cara, temos 16 endereços
 IPV4 multicast que irão

83
00:06:42,440 --> 00:06:47,120
 todos mapeiam exatamente
 o mesmo MAC multicast.

84
00:06:47,120 --> 00:06:50,220
 Mas fica ainda melhor do que isso.

85
00:06:50,220 --> 00:06:59,520
 Porque não apenas 239.111 será mapeado
 para isso, mas 239.129.11.

86
00:06:59,520 --> 00:07:04,520
 Porque lembre-se, esse bit de 8, esse
 bit que normalmente é mapeado para 128

87
00:07:04,520 --> 00:07:07,720
 bit, sempre tem que ser zero.

88
00:07:07,720 --> 00:07:12,240
 Portanto, mesmo que no endereço IPV4 esse
 bit esteja ativado, temos que ativar

89
00:07:12,240 --> 00:07:14,920
 aqui mesmo.

90
00:07:14,920 --> 00:07:22,380
 Portanto, 239.111 e 239.111 também
 serão mapeados para a mesma coisa.

91
00:07:22,380 --> 00:07:27,560
 Sempre que o bit 128 estiver ativado
 neste terceiro octeto, ele cairá

92
00:07:27,560 --> 00:07:30,600
 fora porque tem que ser um zero aqui.

93
00:07:30,600 --> 00:07:35,260
 Então isso significa que para cada uma dessas
 16 combinações, há duas combinações

94
00:07:35,260 --> 00:07:45,080
 que também mapeia. Por exemplo, 224.111
 e 224.129.11, ambos mapeados para o

95
00:07:45,080 --> 00:07:46,540
 exatamente a mesma coisa.

96
00:07:46,540 --> 00:07:56,460
 227.1.5.5, 227.129.5 mapeados
 exatamente para a mesma coisa.

97
00:07:56,460 --> 00:08:03,620
 Então, na realidade, temos 16 números
 no primeiro octeto e dois números

98
00:08:03,620 --> 00:08:05,760
 no segundo octeto.

99
00:08:05,760 --> 00:08:09,060
 Então, realmente temos 32.

100
00:08:09,060 --> 00:08:14,440
 Então, para cada endereço MAC multicast,
 se eu mostrar, por exemplo,

101
00:08:14,440 --> 00:08:17,700
 este, vamos nos livrar do nome
 de Steve Deering aqui.

102
00:08:17,700 --> 00:08:21,360
 Tenho certeza de que ele adoraria ver isso
 nesta apresentação, mas desculpe, Steve,

103
00:08:21,360 --> 00:08:23,600
 vamos nos livrar dele temporariamente.

104
00:08:23,600 --> 00:08:41,740
 Então, se eu lhe desse esse endereço MAC
 multicast, 01005E, opa, não 5.2, 5E.

105
00:08:41,740 --> 00:08:52,480
 E então eu disse, digamos, 7.1.1, deixe-me
 fazer um, vamos fazer dois pontos.

106
00:08:52,480 --> 00:08:58,500
 Chega de manter as coisas consistentes,
 vamos ver aqui.

107
00:08:58,500 --> 00:09:01,380
 Vamos fazer dois pontos aqui também.

108
00:09:01,380 --> 00:09:11,140
 Ok, então se eu perguntasse a você, qual
 é o endereço IPv4 multicast que terminou

109
00:09:11,140 --> 00:09:15,820
 resultando neste endereço MAC multicast?

110
00:09:15,820 --> 00:09:19,960
 Sua resposta teria que
 ser 32 números únicos.

111
00:09:19,960 --> 00:09:25,080
 Porque você diria, bem, Keith, o primeiro
 octeto poderia ter sido qualquer coisa

112
00:09:25,080 --> 00:09:30,840
 de 224 até 239.

113
00:09:30,840 --> 00:09:37,940
 E então o segundo octeto poderia ter
 sido o número 7, ou poderia ser

114
00:09:37,940 --> 00:09:50,920
 128 mais 7, o que seria 135.1.1.

115
00:09:50,920 --> 00:10:01,020
 Portanto, 224.7.135, 225.7.135,
 226.7.135, 111.1.

116
00:10:01,020 --> 00:10:02,780
 Tudo seria mapeado para isso?

117
00:10:02,780 --> 00:10:09,200
 Isso nos dá 32 endereços IP multicast
 mapeados para o mesmo multicast

118
00:10:09,200 --> 00:10:16,680
 Endereço MAC. Agora, neste ponto, você deve
 estar se perguntando: uau, ok, interessante

119
00:10:16,680 --> 00:10:21,500
 exercício matemático, mas onde está a
 relevância do mundo real para isso?

120
00:10:21,500 --> 00:10:23,460
 Onde está a relevância?

121
00:10:23,460 --> 00:10:26,180
 Bem, deixe-me pintar um quadro para você.

122
00:10:26,180 --> 00:10:28,480
 Digamos, vamos pegar isso.

123
00:10:28,480 --> 00:10:38,600
 Digamos que eu tenha 4 laptops.

124
00:10:38,600 --> 00:10:41,800
 Digamos apenas 3, 3 laptops, já que
 estou ficando sem espaço aqui.

125
00:10:41,800 --> 00:10:45,900
 Ok, e vamos tornar isso bem simples aqui.

126
00:10:45,900 --> 00:10:55,180
 Eles estão conectados a um hub, que por
 sua vez está conectado a um multicast

127
00:10:55,180 --> 00:10:59,960
 servidor. É claro que você nunca veria
 isso na vida real, mas você terá

128
00:10:59,960 --> 00:11:02,560
 a ideia por trás disso
 quando eu começar aqui.

129
00:11:02,560 --> 00:11:08,360
 Então, diremos apenas PCA, B e C.

130
00:11:08,360 --> 00:11:13,940
 E digamos que este servidor multicast
 enviará 3 mensagens exclusivas

131
00:11:13,940 --> 00:11:15,440
 fluxos de tráfego.

132
00:11:15,440 --> 00:11:23,820
 Temos 225.2.1.1.

133
00:11:23,820 --> 00:11:31,020
 Temos 239.130.1.1.

134
00:11:31,020 --> 00:11:35,540
 E temos 232.

135
00:11:35,540 --> 00:11:45,220
 Bem, não deveríamos usar, bem,
 você já entendeu, 232.2.1.1.

136
00:11:45,220 --> 00:11:50,020
 E digamos que todos esses fluxos
 sejam de alta definição.

137
00:11:50,020 --> 00:11:54,940
 Cada um tem 5 megabits por segundo.

138
00:11:54,940 --> 00:11:58,700
 Se você realmente recebê-lo, receberá
 5 megabits por segundo.

139
00:11:58,700 --> 00:12:03,580
 Ok, então esses streams
 estão acontecendo agora.

140
00:12:03,580 --> 00:12:08,440
 Todos os três fluxos estão saindo
 deste servidor simultaneamente.

141
00:12:08,440 --> 00:12:12,000
 Se for PC, vamos começar com PCC.

142
00:12:12,000 --> 00:12:20,140
 Se o PCC disser, o único que
 me interessa é 225.2.1.1.

143
00:12:20,140 --> 00:12:21,320
 Então o que ele faz?

144
00:12:21,320 --> 00:12:22,860
 Ele acessa seu cartão Ethernet Nik.

145
00:12:22,860 --> 00:12:25,460
 Ele diz ok, placa Ethernet Nik, é
 isso que quero que você procure.

146
00:12:25,460 --> 00:12:32,200
 Se você já viu um quadro Ethernet
 que começa com 0,01, 0,05e, 0

147
00:12:32,200 --> 00:12:41,500
 0,2, 0,1, 0,1, quero que você pegue isso
 e envie para meu processador para

148
00:12:41,500 --> 00:12:46,960
 em processamento. No momento em que ele faz
 isso, ele programa seu cartão Nik para olhar

149
00:12:46,960 --> 00:12:51,480
 com isso, de repente, seu laptop
 começa a ficar confuso.

150
00:12:51,480 --> 00:12:57,020
 A tela de vídeo dele é apenas pixelizada,
 você não consegue ver nada, não

151
00:12:57,020 --> 00:13:00,700
 faz algum sentido. Além disso, ele
 está tentando baixar seus e-mails e

152
00:13:00,700 --> 00:13:03,700
 demorou uma eternidade para baixar seus e-mails,
 ele pode até estar se conectando

153
00:13:03,700 --> 00:13:06,640
 e desconectando, conectando e desconectando
 de seu servidor de e-mail.

154
00:13:06,640 --> 00:13:09,440
 É como se o laptop dele
 estivesse sendo batido.

155
00:13:09,440 --> 00:13:10,700
 O que está acontecendo?

156
00:13:10,700 --> 00:13:15,700
 Neste ponto, como todos esses três fluxos
 são mapeados exatamente para o mesmo

157
00:13:15,700 --> 00:13:22,240
 endereço MAC da camada dois, agora
 temos três fluxos caindo e seu Nik

158
00:13:22,240 --> 00:13:26,900
 cartão está pegando todos eles porque na
 camada dois, todos eles parecem iguais

159
00:13:26,900 --> 00:13:30,920
 mesmo. Sua placa Ethernet não consegue distinguir
 os endereços da camada três porque

160
00:13:30,920 --> 00:13:31,920
 isso não acontece.

161
00:13:31,920 --> 00:13:33,840
 É apenas uma placa Ethernet
 de camada dois.

162
00:13:33,840 --> 00:13:39,280
 Então, em todos esses três fluxos, um total
 de 15 megas de tráfego está sendo

163
00:13:39,280 --> 00:13:44,700
 direcionado para a unidade central de processamento
 desse cara e sua CPU agora

164
00:13:44,700 --> 00:13:50,820
 jogue ou descarte 10 megas disso para que
 ele possa ver apenas os cinco megas que

165
00:13:50,820 --> 00:13:55,060
 isso quer. Bem, sua CPU provavelmente
 terá muita dificuldade em receber

166
00:13:55,060 --> 00:14:00,240
 consistentes 15 megas de tráfego de entrada
 e tentando descartar dois terços

167
00:14:00,240 --> 00:14:02,220
 disso, 10 megas disso.

168
00:14:02,220 --> 00:14:05,000
 E esse é o problema com a sobreposição
 de 32 para um.

169
00:14:05,000 --> 00:14:07,900
 Agora, isso não é culpa do receptor.

170
00:14:07,900 --> 00:14:10,760
 A culpa é da pessoa que configurou
 este servidor multicast no

171
00:14:10,760 --> 00:14:15,160
 primeiro lugar. Quando você estiver, se você
 estiver em uma situação em que você está

172
00:14:15,160 --> 00:14:20,760
 o administrador multicast e
 será seu trabalho apresentar

173
00:14:20,760 --> 00:14:25,100
 os endereços IP multicast para
 cada um dos fluxos multicast, é

174
00:14:25,100 --> 00:14:29,080
 seu trabalho estar ciente disso e garantir
 que esses fluxos de vídeo não

175
00:14:29,080 --> 00:14:33,060
 sobreposição. E poderia dizer, bem, Keith,
 existe uma maneira fácil de descobrir

176
00:14:33,060 --> 00:14:34,580
 isso? Claro que existe.

177
00:14:34,580 --> 00:14:39,140
 Apenas certifique-se de que de cada
 fluxo multicast os dois últimos

178
00:14:39,140 --> 00:14:41,920
 octetos nunca são iguais.

179
00:14:41,920 --> 00:14:44,780
 Agora, tecnicamente, poderíamos entrar no
 terceiro octeto também, mas se você souber

180
00:14:44,780 --> 00:14:49,960
 que esses últimos 16 bits são sempre
 únicos, seus endereços MAC multicast

181
00:14:49,960 --> 00:14:55,580
 sempre será único porque esses últimos
 16 bits são mapeados um por um

182
00:14:55,580 --> 00:14:58,520
 até o endereço MAC multicast
 na camada dois.

183
00:14:58,520 --> 00:15:02,740
 Então, basta torná-los únicos e você nunca
 terá essa sobreposição de 32 para um

184
00:15:02,740 --> 00:15:05,120
 problema nunca mais.

185
00:15:05,120 --> 00:15:14,220
 É assim que você reconhece endereços
 IP multicast e MAC multicast.

186
00:15:14,220 --> 00:15:22,280
 Agora falei um pouco sobre o que os roteadores
 fazem com quadros multicast.

187
00:15:22,280 --> 00:15:25,980
 Eu disse que quando um roteador recebe um quadro
 multicast, a primeira coisa que ele diz é

188
00:15:25,980 --> 00:15:28,180
 é, isso é algo que preciso processar?

189
00:15:28,180 --> 00:15:32,120
 Porque pode ser um olá EIGRP ou
 um olá OSPF ou algo parecido

190
00:15:32,120 --> 00:15:35,180
 nesse caso direi, ah, estou programado
 para procurar por isso.

191
00:15:35,180 --> 00:15:37,980
 Deixe-me enviá-lo para minha
 CPU para processamento.

192
00:15:37,980 --> 00:15:40,060
 Que param e fazem uma
 pausa por um momento.

193
00:15:40,060 --> 00:15:41,020
 Pense sobre isso.

194
00:15:41,020 --> 00:15:47,680
 Imagine que você é um roteador, ok,
 e está programado para fazer EIGRP,

195
00:15:47,680 --> 00:15:51,760
 tudo bem? Então você está ouvindo especificamente
 os quadros Ethernet chegando

196
00:15:51,760 --> 00:15:58,820
 em ir para 01005E, 0000A, certo?

197
00:15:58,820 --> 00:16:05,700
 Como isso seria mapeado para 10, 2240010
 mapeia para 00A na camada dois.

198
00:16:05,700 --> 00:16:08,440
 Então aqui de vez em quando você
 espera um roteador e diz, ok,

199
00:16:08,440 --> 00:16:11,660
 bem, você sabe, o EIGRP não deveria
 ser tão falador, certo?

200
00:16:11,660 --> 00:16:15,280
 Em um ambiente estável e agradável, a
 cada cinco ou dez segundos você deve

201
00:16:15,280 --> 00:16:19,720
 estar recebendo um pacote EIGRP hello, indo
 para aquele Mac multicast e, em seguida,

202
00:16:19,720 --> 00:16:24,400
 você processa isso. Agora, e se alguém
 que não sabe nada sobre EIGRP

203
00:16:24,400 --> 00:16:29,060
 mas eles sabem que o multicast configura
 seu vídeo multicast de alta definição

204
00:16:29,060 --> 00:16:34,360
 stream, que vai a sete megabits
 por segundo, e eles selecionam,

205
00:16:34,360 --> 00:16:41,920
 Não sei, 239.0010 como
 vestido de destino.

206
00:16:41,920 --> 00:16:46,740
 Adivinha? Na camada dois, esse fluxo de vídeo
 de alta definição será mapeado para

207
00:16:46,740 --> 00:16:50,620
 exatamente o mesmo endereço
 Mac que o EIGRP está usando.

208
00:16:50,620 --> 00:16:53,200
 E agora, de repente, seu roteador,
 em vez de receber apenas um pacote

209
00:16:53,200 --> 00:16:57,420
 a cada cinco ou dez segundos está recebendo
 milhares de pacotes a cada

210
00:16:57,420 --> 00:17:00,300
 segundo, indo para esta
 camada para resolver.

211
00:17:00,300 --> 00:17:03,400
 Você pode apostar que o roteador
 não ficará muito feliz com isso.

212
00:17:03,400 --> 00:17:07,220
 Pode até travar porque precisa levar
 todo o tráfego direcionado para

213
00:17:07,220 --> 00:17:13,640
 a CPU não seja EIGRP.

214
00:17:13,640 --> 00:17:18,200
 Preciso descartar isso para poder isolar
 o pequeno olá EIGRP que está

215
00:17:18,200 --> 00:17:20,320
 ainda chegando a cada cinco
 segundos ou mais.

216
00:17:20,320 --> 00:17:23,200
 Então, fique ciente disso.

217
00:17:23,200 --> 00:17:25,640
 Agora, o que os switches fazem
 ao receber multicast?

218
00:17:25,640 --> 00:17:30,760
 Bem, se você está falando apenas da camada
 dois pura, os switches inundam o multicast

219
00:17:30,760 --> 00:17:34,280
 porque como um switch sabe
 para onde encaminhar algo?

220
00:17:34,280 --> 00:17:42,280
 Bem, quando o quadro Ethernet
 chega, o que um switch faz?

221
00:17:42,280 --> 00:17:46,160
 Ele aprende que na tabela de endereços
 MAC, às vezes chamada de tabela CAM,

222
00:17:46,160 --> 00:17:49,520
 certo? Então é assim que o switch preenche
 a tabela CAM, o endereço MAC

223
00:17:49,520 --> 00:17:52,120
 tabela baseada em endereços
 MAC de origem.

224
00:17:52,120 --> 00:17:57,580
 Bem, os endereços MAC multicast já foram
 vistos na fonte de uma rede Ethernet?

225
00:17:57,580 --> 00:17:59,640
 quadro? Não, eles não são.

226
00:17:59,640 --> 00:18:00,620
 Pelo menos não deveriam ser.

227
00:18:00,620 --> 00:18:02,080
 Isso seria ilegal.

228
00:18:02,080 --> 00:18:06,840
 Então, como um endereço MAC multicast
 só aparece no destino, por

229
00:18:06,840 --> 00:18:11,140
 padrão, um switch não tem como aprendê-lo
 porque não está na fonte.

230
00:18:11,140 --> 00:18:14,320
 Então, o que os switches fazem quando
 recebem um quadro Ethernet e olham

231
00:18:14,320 --> 00:18:16,880
 no destino e não há correspondência
 na mesa?

232
00:18:16,880 --> 00:18:20,100
 Eles inundam. Isso é o que eles fazem.

233
00:18:20,100 --> 00:18:24,180
 Portanto, o comportamento padrão de muitos
 switches é inundar o multicast.

234
00:18:24,180 --> 00:18:27,920
 Agora veremos quando entrarmos no
 tópico de espionagem IGMP que muda