Vimos o tempo todo que quando vocÃª mostra a rota IPM, Ã© muito possÃ­vel
que vocÃª pode ter apenas uma entrada de estrela, certo?
EntÃ£o, se nÃ£o houver fluxo multicast, mas vocÃª recebeu um comagente estelar
junte-se, vocÃª terÃ¡ o estado de estrela-comagee.
E isso significa que estou pronto.
Estou esperando para encaminhar esse trÃ¡fego multicast.
AlguÃ©m me pediu isso.
Uma entrada s-comagee nÃ£o pode ser independente.
NÃ£o posso ficar sozinho.
Em outras palavras, quando o roteador 2 aqui cria esta entrada s-comagee, ele
tambÃ©m precisa criar uma entrada de comagente estelar.
Os dois tÃªm que andar juntos.
EntÃ£o, mesmo que ele nunca tenha recebido um relatÃ³rio de adesÃ£o ao IGMP, mesmo que ele
nunca consegui que um comagente estrela do PIM se juntasse Ã quele conjunto de bits curinga, uma vez que ele
cria uma entrada s-comagee, ele tem que criar uma entrada star-comagee como
bem. Ambos tÃªm que estar lÃ¡.
EntÃ£o, s-comagee, a analogia que Ã s vezes uso Ã© pensar no star-comagee
como sendo como o irmÃ£o mais velho e o s-comagee como sendo como o pequeno
irmÃ£o, certo? O irmÃ£o mais velho de 15 anos pode sair de casa
casa e passear pela vizinhanÃ§a e andar de bicicleta sozinho.
IrmÃ£ozinho que Ã© o s-comagee que sÃ³ tem 7 anos, nÃ£o Ã© permitido
fazer isso, a menos que o irmÃ£o mais velho vÃ¡ com ele.
EntÃ£o nÃ£o sei se eles vÃ£o te ajudar ou nÃ£o, mas pronto.
AlÃ©m disso, quando o trÃ¡fego comeÃ§a a fluir pelo caminho mais curto, Ã© o
entrada s-comagee que Ã© usada para realmente encaminhar esse trÃ¡fego.
EntÃ£o, o que quero dizer Ã© que vocÃª verÃ¡ o comagente estelar que tem alguma saÃ­da
lista de interfaces e vocÃª verÃ¡ o s-comagee que possui uma interface de saÃ­da
lista. O que quer que esteja na lista de interface de saÃ­da do s-comagee, isso Ã©
o importante.
Isso Ã© o que Ã© usado para encaminhar o multicast.
Quando estÃ¡ seguindo o caminho mais curto, se estÃ¡ indo pelo caminho compartilhado
caminho, entÃ£o a entrada do star-comagee Ã© o que dita o encaminhamento do
trÃ¡fego. Algumas coisas adicionais aqui que quero mencionar.
NÃ£o tenho muita redundÃ¢ncia nesta topologia especÃ­fica aqui.
E daÃ­ se eu tivesse algo assim?
Vamos nos livrar dessa linha aqui.
Digamos que temos um switch e dois vizinhos, dois vizinhos upstream.
EntÃ£o, em outras palavras, na verdade nem Ã© preciso lidar com a mudanÃ§a.
Vamos colocar assim.
O roteador um pode usar o roteador dois ou o roteador quatro para chegar Ã origem.
Portanto, neste diagrama especÃ­fico, espero que esteja bem claro que passar por
o ponto de encontro nÃ£o Ã© o caminho mais curto porque temos quatro roteadores
passar para chegar Ã fonte onde sÃ³ podemos passar por dois roteadores
se passarmos pelo roteador dois ou pelo roteador quatro.
EntÃ£o a questÃ£o agora Ã©: ok, quando o roteador precisa abrir seu caminho mais curto
caminho, ele dirÃ¡, hmm, tenho caminhos mais curtos redundantes.
Eu poderia ir pelo vizinho dois ou pelo vizinho quatro.
EntÃ£o a questÃ£o Ã©: para onde ele irÃ¡?
Para onde ele vai enviar seus s, g join?
De acordo com a especificaÃ§Ã£o, Ã© isso que vocÃª verÃ¡.
Ã o vizinho que possui o endereÃ§o IP mais alto.
Ã basicamente nisso que tudo se resume.
EntÃ£o, se isso fosse dois pontos, dois pontos, dois pontos, dois e isso fosse dois pontos, dois pontos
quatro, entÃ£o, nesse caso especÃ­fico, a junÃ§Ã£o s, g teria ocorrido via roteador
quatro. O vizinho com o endereÃ§o IP mais alto quando vocÃª tem redundÃ¢ncia
caminhos. Esse tambÃ©m Ã© o caso da Ã¡rvore compartilhada, certo?
Se eu fosse um roteador e tivesse vÃ¡rias maneiras de chegar ao ponto de encontro
e eles estavam todos na mesma distÃ¢ncia EIGRP ou no mesmo custo OSPF, eu
escolheria qualquer vizinho PIM que tivesse o endereÃ§o IP mais alto.
Ã para lÃ¡ que eu enviaria minhas junÃ§Ãµes para chegar ao ponto de encontro.
EntÃ£o sabemos que s, g permanece criado, mas tambÃ©m deve ser mantido.
EntÃ£o isso nÃ£o Ã© diferente.
Assim como falamos sobre como na Ã¡rvore compartilhada, uma vez construÃ­da, cada
minuto, se eu sou um roteador que possui um receptor conectado diretamente, cada
minuto vou mandar outra estrela, g junte-se ao upstream e assim eles irÃ£o atÃ© o fim
maneira de manter esse estado atualizado ao longo do caminho.
A mesma coisa acontece com o caminho mais curto.
A cada minuto, a cada 60 segundos, os roteadores que precisam desse caminho nos mostrarÃ£o
send s, g junta-se ao upstream para mantÃª-lo atualizado.
EntÃ£o, quando esse estado s, g Ã© excluÃ­do?
Bem, se essas junÃ§Ãµes periÃ³dicas do vizinho downstream pararem, entÃ£o vamos
dizer que a fonte multicast estava atrÃ¡s de mim e eu sou um roteador, vocÃª Ã© um
roteador, e eu sou o caminho mais curto para chegar atÃ© aquele cara.
EntÃ£o, agora, minha lista de interfaces de saÃ­da estÃ¡ apontando para vocÃª.
VocÃª me enviou um s, g join indicando seu interesse.
Coloquei vocÃª na lista de interfaces de saÃ­da.
Portanto, Ã© sua responsabilidade a cada minuto me enviar s, g joins para atualizar
esse. Mas e se houver um switch ou hub entre nÃ³s e o seu
a conexÃ£o com esse switch ou hub cai?
Eu nÃ£o sei disso.
No que me diz respeito, vocÃª ainda estÃ¡ vivo.
Bem, nesse caso especÃ­fico, se as junÃ§Ãµes periÃ³dicas pararem, mais uma vez,
aquele cronÃ´metro de 210 segundos, esse Ã© o nÃºmero mÃ¡gico, se depois de 210 segundos,
NÃ£o estou mais recebendo essas junÃ§Ãµes suas, entÃ£o irei excluÃ­-las
lista de interfaces de saÃ­da.
Agora, mais uma vez, naquela situaÃ§Ã£o especÃ­fica, muito provavelmente o que aconteceria
acontecer Ã© que eu diria, bem, espere um segundo, perdi meu vizinho PIM, certo?
Porque no caso do PIM, vocÃª tambÃ©m estÃ¡ me enviando alÃ´s PIM a cada 30
segundos. E se eu perdi trÃªs deles, declaro que um vizinho estÃ¡ morto.
EntÃ£o, seria de se supor que se esse link entre vocÃª e o switch fosse
desligado, o PIM detectaria o vizinho perdido em, vimos 105 segundos, que
foi aquele cronÃ´metro, antes que o cronÃ´metro de 210 segundos expirasse.
NÃ£o vou testar isso agora.
Mas eu sÃ³ quero que vocÃª saiba, de acordo com a especificaÃ§Ã£o, se o
junÃ§Ãµes periÃ³dicas param em 210 segundos, esse Ã© um critÃ©rio para remover
essa interface da lista de interfaces de saÃ­da.
Se a fonte multicast parar de transmitir, mais uma vez, 210 segundos depois,
Vou esperar, certo?
Se a fonte multicast parar de me atingir na nuca, 210
segundos depois, removerei minhas interfaces de saÃ­da.
E isso acontece com todos os roteadores desativados ao longo do caminho.
EntÃ£o, nesta topologia especÃ­fica aqui, se a fonte parar, 210 segundos
mais tarde, o roteador quatro removerÃ¡ sua interface e o roteador um removerÃ¡
sua interface da lista de interfaces de saÃ­da.
Ou se vocÃª receber uma mensagem de remoÃ§Ã£o do PIM.
Portanto, a mensagem de ameixa Ã© uma forma de dizer: ei, nÃ£o quero mais isso.
Como neste caso especÃ­fico, uma vez que o roteador um tenha aberto com sucesso
subindo em sua Ã¡rvore de caminho mais curto, ele enviarÃ¡ uma mensagem de ameixa atÃ© o ponto de encontro
ponto, dizendo, nÃ£o preciso mais deste galho da Ã¡rvore.
EntÃ£o, podemos realmente ver isso.
Acho que ainda nÃ£o nos concentramos em uma mensagem de poda.
Mas vamos voltar Ã nossa topologia original aqui.
Agora acho que o roteador cinco neste momento provavelmente jÃ¡ terminou, enviando seus pings.
Sim. OK. E se jÃ¡ se passaram 210 segundos, o que provavelmente aconteceu, deverÃ­amos
nÃ£o vejo mais o estado s, g em nenhum roteador.
Sim, isso acabou.
Isso expirou. EntÃ£o vou prosseguir e comeÃ§ar de novo, o ping.
E o que vamos procurar especificamente agora Ã© uma vez que o roteador
dois abre esse caminho, devemos vÃª-lo enviar uma remoÃ§Ã£o de PIM para o roteador oito.
E entÃ£o vamos em frente e capturar aquela ameixa sÃ³ para ver como fica
como. Portanto, no roteador oito, quero que zero barra um seja sua interface de entrada.
E de acordo com isso, serÃ¡ zero barra dois no switch.
OK. EntÃ£o vamos nos preparar.
Vou para o roteador cinco.
E vamos iniciar o rastreamento do atirador.
OK. Esta Ã© provavelmente a ameixa aqui.
Vamos descobrir. Sim.
NÃºmero de ameixas um.
EntÃ£o, mais uma vez, o bit RP estÃ¡ definido, o que significa que isso estÃ¡ subindo no compartilhamento
Ã¡rvore atÃ© o ponto de encontro.
E estamos dizendo que estou eliminando esta fonte e este grupo.
Portanto, Ã© exatamente o mesmo formato de mensagem de uma junÃ§Ã£o PIM, exceto que em vez de
juntando-se, temos podar.
JÃ¡ falamos sobre como as ameixas PIM usam o mesmo formato do PIM
joins usados ââpara encorajar vizinhos upstream a parar de encaminhar multicast
trÃ¡fego para nÃ³s. Agora, por que diz encorajar, por que nÃ£o forÃ§ar o
vizinho upstream pare de encaminhar trÃ¡fego multicast para nÃ³s?
Bem, aqui estÃ¡ o porquÃª.
Se eu tivesse esse tipo de situaÃ§Ã£o em que eu tivesse, digamos, vamos apenas fazer
Ã© fÃ¡cil, um hub. OK.
Digamos que este seja meu RP.
Temos roteador um, roteador dois e roteador trÃªs.
Vou me conectar ao mesmo hub.
OK. Digamos que neste momento ambos os PCs, PCA e PCB, sejam multicast
receptores. E ambos estÃ£o recebendo exatamente o mesmo grupo.
VocÃª sabe, eles estÃ£o assistindo ao vÃ­deo de apresentaÃ§Ã£o do CEO agora.
Portanto, o multicast estÃ¡ fluindo.
E no roteador trÃªs, temos estrela e estado.
E Ethernet rÃ¡pida zero, zero estÃ¡ na lista de interfaces de saÃ­da.
OK. Se de repente o receptor A enviar uma mensagem de saÃ­da IGMP porque
ele nÃ£o estÃ¡ mais interessado naquele fluxo, isso farÃ¡ com que o roteador
um. Ele vai dizer, ok, vou deletar esta interface do
minha lista de interfaces de saÃ­da.
Ele vai dizer, ah, nÃ£o tenho mais interfaces na minha interface de saÃ­da
lista. Minha lista de interfaces de saÃ­da Ã© nula.
EntÃ£o isso vai fazer com que ele diga, tudo bem, nÃ£o preciso mais disso.
EntÃ£o ele vai mandar uma mensagem PMPRUN, que acabamos de ver no sniffer
vestÃ­gio. Isso vai para o hub.
O roteador dois verÃ¡ isso.
O roteador trÃªs verÃ¡ isso.
Agora, se o roteador trÃªs removesse imediatamente essa interface, terÃ­amos
um problema. Porque o PCB pararia de receber o fluxo.
E ele ainda estÃ¡ interessado.
Ele Ã© um receptor quieto e interessado.
Portanto, a maneira como o PEM funciona Ã© que, neste caso especÃ­fico, quando o roteador
trÃªs recebe esta ameixa, ele vai esperar alguns segundos.
Acho que sÃ£o cerca de cinco segundos, mas nÃ£o me cite sobre isso.
Mas sÃ£o alguns segundos.
NÃ£o Ã© muito tempo porque a suposiÃ§Ã£o Ã©, ei, se o roteador dois
tambÃ©m viu aquela ameixa, o que ele vai fazer?
Ele vai dizer, espere um segundo.
Ainda tenho alguÃ©m interessado.
E isso farÃ¡ com que ele envie outra junÃ§Ã£o PEM.
Neste caso especÃ­fico, eles provavelmente serÃ£o uma junÃ§Ã£o s-coma-g porque
ele conhece a fonte.
E isso substituirÃ¡ a poda.
E isso manterÃ¡ esta interface na lista de interfaces de saÃ­da.
Ã por isso que dizemos que as podas PEM encorajam o vizinho rio acima.
Porque neste caso especÃ­fico, o roteador nÃ£o vai dizer, cara, eu mando uma ameixa,
mas ainda estou recebendo esse multicast.
Bem, nÃ£o hÃ¡ realmente nada que ele possa fazer sobre isso.
A cada minuto ele continuarÃ¡ enviando uma ameixa e dizendo, ei, por favor, poda
meu. E o roteador dois irÃ¡ substituir isso enviando uma nota, continue assim,
continue. EntÃ£o Ã© isso que os desencadeia.
Uma poda PEM Ã© acionada quando vocÃª recebe algum tipo de licenÃ§a
mensagem do seu receptor ou se uma interface downstream expirar,
certo? Talvez o destinatÃ¡rio vÃ¡ embora, nunca envie uma licenÃ§a e, eventualmente,
vocÃª, vocÃª sabe, o IgMP atinge o tempo limite dessa interface, o que provocaria uma remoÃ§Ã£o
tambÃ©m. Ou se vocÃª receber uma ameixa seca de um vizinho a jusante.
Portanto, neste caso especÃ­fico, quando o roteador B, ou PCB, finalmente decide
que ele terminou, ele nÃ£o quer mais assistir.
Bem, isso farÃ¡ com que o roteador dois envie sua mensagem de remoÃ§Ã£o.
Isso removerÃ¡ esta interface da lista de interfaces de saÃ­da.
E agora o roteador trÃªs percebe que sua lista de interfaces de saÃ­da Ã©
null, isso farÃ¡ com que ele envie seu prÃ³prio upstream de remoÃ§Ã£o de PEM.
Isso praticamente conclui esta seÃ§Ã£o sobre como ingressar no
Ã¡rvore de caminho mais curto.
Ah, hÃ¡ outra coisa que queremos verificar antes de terminar.
Deixe-me voltar. Queremos verificar isso.
Queremos ver, ok, quando o multicast comeÃ§a a fluir pelo canal compartilhado
Ã¡rvore, de acordo com a RFC, a primeira pessoa a mudar tem que
seja o roteador folha.
Que esse roteador intermediÃ¡rio do roteador oito aqui, porque ele nÃ£o tem
receptores conectados, nÃ£o Ã© permitido fazer esse processo de transiÃ§Ã£o.
EntÃ£o, vamos ver se isso Ã© realmente verdade.
Tenho certeza que provavelmente Ã©.
Mas vamos ver aqui.
Como vamos testar isso?
Bem, aqui estÃ¡ o que eu acho que vai acontecer.
Se tudo correr de acordo com o que a RFC diz que deveria acontecer, entÃ£o quando
roteador dois, o roteador folha recebe o primeiro pacote multicast, ele deve
junte-se Ã Ã¡rvore do caminho mais curto.
Assim que a Ã¡rvore do caminho mais curto for aberta, ele deverÃ¡ podar o roteador oito.
O roteador oito deve entÃ£o enviar uma remoÃ§Ã£o ou o roteador trÃªs.
EntÃ£o, de certa forma, nunca deverÃ­amos ver uma junÃ§Ã£o S, G originada do roteador
oito. DeverÃ­amos ver ameixas provenientes dele, mas nÃ£o deverÃ­amos ver
S, G junta-se originado com seu endereÃ§o IP.
EntÃ£o, aqui estÃ¡ como vamos testar isso.
Vamos apenas mudar para todas as interfaces conectadas ao roteador
oito, que Ã© zero dois e zero treze.
Capturaremos todo o trÃ¡fego de entrada e saÃ­da e veremos se ele algum dia
na verdade, envia uma junÃ§Ã£o S, G, que nÃ£o deverÃ­amos ver.
Tudo bem, entÃ£o isso estÃ¡ feito.
Vamos limpar o estado MROUT, mostrar IP, MROUT.
Ok, entÃ£o o estado S, G jÃ¡ expirou.
Vamos para o interruptor.
EntÃ£o, agora estamos monitorando zero dois.
Queremos adicionar zero treze a essa lista.
Tudo bem, vamos voltar ao roteador cinco.
Comece nosso rastreamento de atirador.
Ok, neste momento nÃ£o estou vendo o multicast passar pelo roteador
mais oito, porque no momento tudo o que estou vendo sÃ£o interfaces
conectado ao roteador oito, e nÃ£o estou vendo nenhum multicast acontecendo
por lÃ¡. Parou aqui mesmo.
EntÃ£o vamos ver aqui oito dois oito dois.
Esse Ã© o roteador dois oito quatro oito oito.
Esse Ã© o roteador oito oito quatro oito oito.
Ok, entÃ£o o que o roteador oito enviou ali?
Roteador oito oito quatro oito oito.
Ele enviou uma ameixa.
Ok, entÃ£o Ã© ele enviando uma ameixa para a Ã¡rvore compartilhada, e ele fez isso
em resposta Ã ameixa que recebeu.
Portanto, esta Ã© provavelmente a ameixa que ele recebeu.
EntÃ£o isso Ã©, sim, entÃ£o esta Ã© a remoÃ§Ã£o do roteador dois que estÃ¡ conectado
para o nosso receptor que disse, ei, olha, vizinho oito dois oito oito.
Eu nÃ£o preciso mais de vocÃª.
Vamos podar essa Ã¡rvore compartilhada entre vocÃª e eu.
E o roteador oito encaminhou aquele podador para o ponto de encontro.
EntÃ£o, com certeza, nÃ£o vemos nenhuma mensagem de junÃ§Ã£o do roteador oito.
Aqui ele estÃ¡ ingressando no RP automÃ¡tico, entÃ£o isso nÃ£o conta.
EntÃ£o, com certeza, isso confirma o que a RFC diz, que apenas os roteadores folha
ou os roteadores de Ãºltimo salto podem ingressar na Ã¡rvore de caminho mais curto.