Ok, entÃ£o o Mac multicast, lembre-se que estamos falando de um destino
EndereÃ§o Mac, Ã© parcialmente derivado do endereÃ§o IP multicast real
que fica acima dele na camada de rede.
Portanto, esses sÃ£o os dois OUIs reservados que vocÃª deve procurar para multicast.
Se vocÃª alguma vez vir um quadro Ethernet indo para um destino comeÃ§ando
com 01005E, isso deve fazer vocÃª dizer aha, esse quadro estÃ¡ carregando
um pacote multicast IP versÃ£o 4.
EntÃ£o esse Ã© o OUI reservado para dados multicast IPv4.
E entÃ£o, se vocÃª vir alguma coisa indo para 33333, isso estÃ¡ reservado para
Multicast IPv6.
Ok, entÃ£o vamos falar um pouco sobre como derivamos as coisas.
Em primeiro lugar, vamos comeÃ§ar com o IPv6.
IPv6 Ã© muito fÃ¡cil e depois voltarei para IPv4.
Digamos que meu endereÃ§o IPv6 multicast, vou inventar algo
aqui. Digamos que estava indo para FF0E, entÃ£o este Ã© um multicast global, e
digamos apenas 11111 e depois AAAA, BBBB, CCC, vamos ver, 1, 2, 3, 4,
5, preciso de mais trÃªs.
E entÃ£o 2222, 777, 1, 2, 3, 4, 5, 6, 7, entÃ£o faremos apenas o Ãºltimo octeto,
meio que execute DDD.
Ok, tudo o que faremos Ã© quando a fonte multicast gerar este
endereÃ§o como o endereÃ§o de destino na camada trÃªs, depois disso, quando ele estiver
criando seu quadro Ethernet, tudo o que ele farÃ¡ Ã© pegar os Ãºltimos 32
bits, que neste caso Ã© 777 e DDDD, e ele vai corrigir isso
aqui, onde estÃ£o esses X.
Portanto, na camada dois, o quadro Ethernet serÃ¡ destinado a 333 dois pontos 777
dois pontos DDDD. EntÃ£o isso Ã© muito fÃ¡cil.
Lembre-se de que os Ãºltimos 32 bits do endereÃ§o multicast IPv6 sÃ£o diretamente
mapeado para os Ãºltimos 32 bits do endereÃ§o MAC de destino do quadro Ethernet.
Agora, no mundo do IPv4, mapear isso Ã© meio que um pesadelo.
EntÃ£o tenha paciÃªncia comigo aqui, se vocÃª ainda nÃ£o tomou seu cafÃ©, vocÃª pode querer
dar um grande gole neste momento, porque isso normalmente faz com que as pessoas
os olhos ficam vidrados.
Mas vamos seguir em frente e analisar isso porque acho que vocÃª deveria
saber disso. EntÃ£o, em primeiro lugar, conhecemos meu endereÃ§o MAC multicast na camada
dois Ã© 01005E. E agora vocÃª pode pensar, ok, bem, isso Ã© metade do
endereÃ§o, certo? Um endereÃ§o MAC tem 48 bits.
Isso Ã© metade. EntÃ£o vocÃª pode pensar, ok, ainda tenho 24 bits para mapear.
Bem, nÃ£o exatamente.
Se eu converter isso em binÃ¡rio para o resto, apenas parte, o
o prÃ³ximo bit deve ser zero.
E entÃ£o vocÃª tem 12345678 dois pontos 12345678.
Eu simplesmente farei isso.
Dois pontos 12345678. Estou ficando sem espaÃ§o, mas vocÃª entendeu.
Portanto, dos meus 24 bits restantes, na verdade sÃ³ tenho 23 bits.
Esse aqui tem que ser zerado.
E se vocÃª estiver olhando para isso e se perguntando o quÃª?
Bem, isso nÃ£o faz sentido.
Vou te dizer uma coisa, hÃ¡ uma histÃ³ria interessante.
NÃ£o vou entrar na histÃ³ria, mas Ã© isso que vocÃª deveria pesquisar no Google
para descobrir por que eles acabaram fazendo assim?
Pesquise isso no Google. Google o nome Steve.
Sobrenome, Deering.
Mac multicast. Google isso.
Steve Deering Multicast Mac.
E vocÃª poderÃ¡ encontrar uma histÃ³ria interessante sobre Steve Deering.
um dos pioneiros originais do multicast.
Ele fez grande parte do trabalho inicial nisso.
E vocÃª encontrarÃ¡ uma histÃ³ria interessante sobre quando ele era estudante de graduaÃ§Ã£o,
uma pequena interaÃ§Ã£o que ele teve com seu professor que tinha a ver com dinheiro,
e acabou com uma coisa estranha aqui, com apenas 23 bits sendo
disponÃ­vel. Ok, entÃ£o como mapeamos o endereÃ§o IP multicast?
Bem, se vocÃª puder manter isso em mente, agora deve ser bem fÃ¡cil.
Basta pegar os Ãºltimos 23 bits do endereÃ§o IP multicast e mapeÃ¡-los aqui.
Digamos que meu endereÃ§o IP multicast seja 239.
Bem, nÃ£o importa qual seja o primeiro octeto, seja 224 atÃ© 239, Ã© sempre
vou mapear atÃ© 5e, certo?
Como esse octeto estÃ¡ meio cancelado, sempre se tornarÃ¡
5e. E agora digamos que eu tenha um fluxo multicast de 239.
vamos apenas tornar isso mais fÃ¡cil.
1.1.1. Esse Ã© o meu endereÃ§o IP multicast.
Bem, o endereÃ§o MAC multicast resultante seria 01005e, e esses bits
seria mapeado aqui.
EntÃ£o seria 01005e, 1111.
Bem, e se eu tivesse 225.1.1?
Seria exatamente a mesma coisa.
0111, todos eles seriam mapeados para o mesmo MAC multicast.
EntÃ£o, vamos somar isso por um segundo.
Se vocÃª fizer algumas contas rÃ¡pidas, se comeÃ§armos em 224 e subirmos para 239,
quantos nÃºmeros Ãºnicos sÃ£o esses?
Vou te dizer agora, sÃ£o um total de 16 nÃºmeros Ãºnicos.
De 224 a 239 sÃ£o 16 combinaÃ§Ãµes de bytes.
EntÃ£o, de cara, temos 16 endereÃ§os IPV4 multicast que irÃ£o
todos mapeiam exatamente o mesmo MAC multicast.
Mas fica ainda melhor do que isso.
Porque nÃ£o apenas 239.111 serÃ¡ mapeado para isso, mas 239.129.11.
Porque lembre-se, esse bit de 8, esse bit que normalmente Ã© mapeado para 128
bit, sempre tem que ser zero.
Portanto, mesmo que no endereÃ§o IPV4 esse bit esteja ativado, temos que ativar
aqui mesmo.
Portanto, 239.111 e 239.111 tambÃ©m serÃ£o mapeados para a mesma coisa.
Sempre que o bit 128 estiver ativado neste terceiro octeto, ele cairÃ¡
fora porque tem que ser um zero aqui.
EntÃ£o isso significa que para cada uma dessas 16 combinaÃ§Ãµes, hÃ¡ duas combinaÃ§Ãµes
que tambÃ©m mapeia. Por exemplo, 224.111 e 224.129.11, ambos mapeados para o
exatamente a mesma coisa.
227.1.5.5, 227.129.5 mapeados exatamente para a mesma coisa.
EntÃ£o, na realidade, temos 16 nÃºmeros no primeiro octeto e dois nÃºmeros
no segundo octeto.
EntÃ£o, realmente temos 32.
EntÃ£o, para cada endereÃ§o MAC multicast, se eu mostrar, por exemplo,
este, vamos nos livrar do nome de Steve Deering aqui.
Tenho certeza de que ele adoraria ver isso nesta apresentaÃ§Ã£o, mas desculpe, Steve,
vamos nos livrar dele temporariamente.
EntÃ£o, se eu lhe desse esse endereÃ§o MAC multicast, 01005E, opa, nÃ£o 5.2, 5E.
E entÃ£o eu disse, digamos, 7.1.1, deixe-me fazer um, vamos fazer dois pontos.
Chega de manter as coisas consistentes, vamos ver aqui.
Vamos fazer dois pontos aqui tambÃ©m.
Ok, entÃ£o se eu perguntasse a vocÃª, qual Ã© o endereÃ§o IPv4 multicast que terminou
resultando neste endereÃ§o MAC multicast?
Sua resposta teria que ser 32 nÃºmeros Ãºnicos.
Porque vocÃª diria, bem, Keith, o primeiro octeto poderia ter sido qualquer coisa
de 224 atÃ© 239.
E entÃ£o o segundo octeto poderia ter sido o nÃºmero 7, ou poderia ser
128 mais 7, o que seria 135.1.1.
Portanto, 224.7.135, 225.7.135, 226.7.135, 111.1.
Tudo seria mapeado para isso?
Isso nos dÃ¡ 32 endereÃ§os IP multicast mapeados para o mesmo multicast
EndereÃ§o MAC. Agora, neste ponto, vocÃª deve estar se perguntando: uau, ok, interessante
exercÃ­cio matemÃ¡tico, mas onde estÃ¡ a relevÃ¢ncia do mundo real para isso?
Onde estÃ¡ a relevÃ¢ncia?
Bem, deixe-me pintar um quadro para vocÃª.
Digamos, vamos pegar isso.
Digamos que eu tenha 4 laptops.
Digamos apenas 3, 3 laptops, jÃ¡ que estou ficando sem espaÃ§o aqui.
Ok, e vamos tornar isso bem simples aqui.
Eles estÃ£o conectados a um hub, que por sua vez estÃ¡ conectado a um multicast
servidor. Ã claro que vocÃª nunca veria isso na vida real, mas vocÃª terÃ¡
a ideia por trÃ¡s disso quando eu comeÃ§ar aqui.
EntÃ£o, diremos apenas PCA, B e C.
E digamos que este servidor multicast enviarÃ¡ 3 mensagens exclusivas
fluxos de trÃ¡fego.
Temos 225.2.1.1.
Temos 239.130.1.1.
E temos 232.
Bem, nÃ£o deverÃ­amos usar, bem, vocÃª jÃ¡ entendeu, 232.2.1.1.
E digamos que todos esses fluxos sejam de alta definiÃ§Ã£o.
Cada um tem 5 megabits por segundo.
Se vocÃª realmente recebÃª-lo, receberÃ¡ 5 megabits por segundo.
Ok, entÃ£o esses streams estÃ£o acontecendo agora.
Todos os trÃªs fluxos estÃ£o saindo deste servidor simultaneamente.
Se for PC, vamos comeÃ§ar com PCC.
Se o PCC disser, o Ãºnico que me interessa Ã© 225.2.1.1.
EntÃ£o o que ele faz?
Ele acessa seu cartÃ£o Ethernet Nik.
Ele diz ok, placa Ethernet Nik, Ã© isso que quero que vocÃª procure.
Se vocÃª jÃ¡ viu um quadro Ethernet que comeÃ§a com 0,01, 0,05e, 0
0,2, 0,1, 0,1, quero que vocÃª pegue isso e envie para meu processador para
em processamento. No momento em que ele faz isso, ele programa seu cartÃ£o Nik para olhar
com isso, de repente, seu laptop comeÃ§a a ficar confuso.
A tela de vÃ­deo dele Ã© apenas pixelizada, vocÃª nÃ£o consegue ver nada, nÃ£o
faz algum sentido. AlÃ©m disso, ele estÃ¡ tentando baixar seus e-mails e
demorou uma eternidade para baixar seus e-mails, ele pode atÃ© estar se conectando
e desconectando, conectando e desconectando de seu servidor de e-mail.
Ã como se o laptop dele estivesse sendo batido.
O que estÃ¡ acontecendo?
Neste ponto, como todos esses trÃªs fluxos sÃ£o mapeados exatamente para o mesmo
endereÃ§o MAC da camada dois, agora temos trÃªs fluxos caindo e seu Nik
cartÃ£o estÃ¡ pegando todos eles porque na camada dois, todos eles parecem iguais
mesmo. Sua placa Ethernet nÃ£o consegue distinguir os endereÃ§os da camada trÃªs porque
isso nÃ£o acontece.
Ã apenas uma placa Ethernet de camada dois.
EntÃ£o, em todos esses trÃªs fluxos, um total de 15 megas de trÃ¡fego estÃ¡ sendo
direcionado para a unidade central de processamento desse cara e sua CPU agora
jogue ou descarte 10 megas disso para que ele possa ver apenas os cinco megas que
isso quer. Bem, sua CPU provavelmente terÃ¡ muita dificuldade em receber
consistentes 15 megas de trÃ¡fego de entrada e tentando descartar dois terÃ§os
disso, 10 megas disso.
E esse Ã© o problema com a sobreposiÃ§Ã£o de 32 para um.
Agora, isso nÃ£o Ã© culpa do receptor.
A culpa Ã© da pessoa que configurou este servidor multicast no
primeiro lugar. Quando vocÃª estiver, se vocÃª estiver em uma situaÃ§Ã£o em que vocÃª estÃ¡
o administrador multicast e serÃ¡ seu trabalho apresentar
os endereÃ§os IP multicast para cada um dos fluxos multicast, Ã©
seu trabalho estar ciente disso e garantir que esses fluxos de vÃ­deo nÃ£o
sobreposiÃ§Ã£o. E poderia dizer, bem, Keith, existe uma maneira fÃ¡cil de descobrir
isso? Claro que existe.
Apenas certifique-se de que de cada fluxo multicast os dois Ãºltimos
octetos nunca sÃ£o iguais.
Agora, tecnicamente, poderÃ­amos entrar no terceiro octeto tambÃ©m, mas se vocÃª souber
que esses Ãºltimos 16 bits sÃ£o sempre Ãºnicos, seus endereÃ§os MAC multicast
sempre serÃ¡ Ãºnico porque esses Ãºltimos 16 bits sÃ£o mapeados um por um
atÃ© o endereÃ§o MAC multicast na camada dois.
EntÃ£o, basta tornÃ¡-los Ãºnicos e vocÃª nunca terÃ¡ essa sobreposiÃ§Ã£o de 32 para um
problema nunca mais.
Ã assim que vocÃª reconhece endereÃ§os IP multicast e MAC multicast.
Agora falei um pouco sobre o que os roteadores fazem com quadros multicast.
Eu disse que quando um roteador recebe um quadro multicast, a primeira coisa que ele diz Ã©
Ã©, isso Ã© algo que preciso processar?
Porque pode ser um olÃ¡ EIGRP ou um olÃ¡ OSPF ou algo parecido
nesse caso direi, ah, estou programado para procurar por isso.
Deixe-me enviÃ¡-lo para minha CPU para processamento.
Que param e fazem uma pausa por um momento.
Pense sobre isso.
Imagine que vocÃª Ã© um roteador, ok, e estÃ¡ programado para fazer EIGRP,
tudo bem? EntÃ£o vocÃª estÃ¡ ouvindo especificamente os quadros Ethernet chegando
em ir para 01005E, 0000A, certo?
Como isso seria mapeado para 10, 2240010 mapeia para 00A na camada dois.
EntÃ£o aqui de vez em quando vocÃª espera um roteador e diz, ok,
bem, vocÃª sabe, o EIGRP nÃ£o deveria ser tÃ£o falador, certo?
Em um ambiente estÃ¡vel e agradÃ¡vel, a cada cinco ou dez segundos vocÃª deve
estar recebendo um pacote EIGRP hello, indo para aquele Mac multicast e, em seguida,
vocÃª processa isso. Agora, e se alguÃ©m que nÃ£o sabe nada sobre EIGRP
mas eles sabem que o multicast configura seu vÃ­deo multicast de alta definiÃ§Ã£o
stream, que vai a sete megabits por segundo, e eles selecionam,
NÃ£o sei, 239.0010 como vestido de destino.
Adivinha? Na camada dois, esse fluxo de vÃ­deo de alta definiÃ§Ã£o serÃ¡ mapeado para
exatamente o mesmo endereÃ§o Mac que o EIGRP estÃ¡ usando.
E agora, de repente, seu roteador, em vez de receber apenas um pacote
a cada cinco ou dez segundos estÃ¡ recebendo milhares de pacotes a cada
segundo, indo para esta camada para resolver.
VocÃª pode apostar que o roteador nÃ£o ficarÃ¡ muito feliz com isso.
Pode atÃ© travar porque precisa levar todo o trÃ¡fego direcionado para
a CPU nÃ£o seja EIGRP.
Preciso descartar isso para poder isolar o pequeno olÃ¡ EIGRP que estÃ¡
ainda chegando a cada cinco segundos ou mais.
EntÃ£o, fique ciente disso.
Agora, o que os switches fazem ao receber multicast?
Bem, se vocÃª estÃ¡ falando apenas da camada dois pura, os switches inundam o multicast
porque como um switch sabe para onde encaminhar algo?
Bem, quando o quadro Ethernet chega, o que um switch faz?
Ele aprende que na tabela de endereÃ§os MAC, Ã s vezes chamada de tabela CAM,
certo? EntÃ£o Ã© assim que o switch preenche a tabela CAM, o endereÃ§o MAC
tabela baseada em endereÃ§os MAC de origem.
Bem, os endereÃ§os MAC multicast jÃ¡ foram vistos na fonte de uma rede Ethernet?
quadro? NÃ£o, eles nÃ£o sÃ£o.
Pelo menos nÃ£o deveriam ser.
Isso seria ilegal.
EntÃ£o, como um endereÃ§o MAC multicast sÃ³ aparece no destino, por
padrÃ£o, um switch nÃ£o tem como aprendÃª-lo porque nÃ£o estÃ¡ na fonte.
EntÃ£o, o que os switches fazem quando recebem um quadro Ethernet e olham
no destino e nÃ£o hÃ¡ correspondÃªncia na mesa?
Eles inundam. Isso Ã© o que eles fazem.
Portanto, o comportamento padrÃ£o de muitos switches Ã© inundar o multicast.
Agora veremos quando entrarmos no tÃ³pico de espionagem IGMP que muda