Ok, antes de entrarmos nos detalhes do PIM como um multicast
protocolo de roteamento, vamos dar uma olhada em um nÃ­vel realmente alto do que Ã© multicast
protocolos de roteamento, por que precisamos deles, que problema eles foram projetados
resolver. EntÃ£o sabemos que temos esse conceito de fontes e receptores,
a origem Ã© algum servidor que estÃ¡ bombeando trÃ¡fego multicast
e atingindo seu roteador, esse roteador o estÃ¡ derrubando porque nÃ£o hÃ¡
ideia de onde deveria ir.
E do outro lado da rede vocÃª tem seus receptores seus laptops
seus PCs que desejam esse trÃ¡fego multicast, mas seu gateway padrÃ£o possui
nÃ£o faÃ§o ideia de onde estÃ¡ a fonte.
EntÃ£o, como conectamos os dois?
E essa Ã© a razÃ£o pela qual precisamos de protocolos de roteamento multicast para
construir essa ramificaÃ§Ã£o, para conectÃ¡-los, para construir esta distribuiÃ§Ã£o multicast
Ã¡rvore. EntÃ£o precisamos criar essa Ã¡rvore.
E eu falei no vÃ­deo anterior que temos dois nÃ­veis bÃ¡sicos de alto nÃ­vel
maneiras de fazer isso.
Um mÃ©todo, chamado modelo push, usado no modo denso
protocolos, significa simplesmente que vamos inundar a rede com esse multicast
trÃ¡fego. VocÃª definitivamente chegarÃ¡ aos receptores e todos os outros
galhos da Ã¡rvore onde caberÃ¡ aos roteadores podÃ¡-los
ramificaÃ§Ãµes para dizer, ei, roteador upstream, pare de enviar isso para mim.
NÃ£o tenho ninguÃ©m a jusante para mim que realmente queira isso.
O outro modelo Ã© o modo esparso, o que significa, OK, uma vez que os receptores indiquem
seu interesse para o gateway padrÃ£o, o gateway padrÃ£o agora precisa
acionar algum tipo de mensagem de junÃ§Ã£o multicast dizendo: OK, vou enviar
uma mensagem upstream dizendo, ei, roteador acima de mim.
Se vocÃª receber esta mensagem, esse fluxo multicast, estou aqui.
Eu quero aquilo. A questÃ£o entÃ£o Ã©: OK, bem, onde estÃ¡ o seu padrÃ£o
gateway enviar isso?
Porque talvez ele tenha cinco ou seis roteadores instalados a montante dele.
Para qual deles ele envia esta junÃ§Ã£o?
EntÃ£o, para responder a isso, aqui estÃ¡ uma boa analogia que fiz.
Pense em namorar, certo?
Rapazes e meninas namorando tentando se encontrar.
EntÃ£o, um protocolo de modo denso seria tipo, vocÃª Ã© o cara, vocÃª anda
em uma boate, e para encontrar seu companheiro perfeito, basta caminhar
atÃ© cada garota que estÃ¡ aqui dizendo, ei, eu te amo.
VocÃª gostaria de se casar comigo?
Eu te amo. VocÃª gostaria de se casar comigo?
Claro, vocÃª leva um tapa vÃ¡rias vezes por estar fazendo isso.
Mas espero que, eventualmente, vocÃª encontre seu receptor, certo?
No canto mais distante, a garota que estÃ¡ bebendo muita cerveja, ela vai dizer:
sim, eu quero me casar com vocÃª.
E agora vocÃª encontrou seu receptor.
VocÃª Ã© a fonte.
Ela Ã© a receptora.
VocÃª tinha que passar por todos os outros primeiro e ser podado novamente.
Mas, eventualmente, vocÃª encontrou quem estava procurando.
Ã como um protocolo de modo denso.
Um protocolo de modo esparso Ã© como, em vez de fazer isso e arriscar tudo
essa rejeiÃ§Ã£o, vocÃª usa um serviÃ§o de namoro.
EntÃ£o vocÃª tem essa empresa intermediÃ¡ria chamada serviÃ§o de namoro, vocÃª sabe,
tanto faz, eharmony.com ou qualquer que seja o grande problema hoje em dia.
E a fonte, vocÃª, vai ao serviÃ§o de namoro e cria um perfil.
E vocÃª diz, ei, esse sou eu.
Eu sou tÃ£o maravilhoso e Ã³timo.
Eu ganho US$ 5 milhÃµes por ano.
Eu dirijo uma Ferrari.
Por favor, case comigo.
Certo? EntÃ£o vocÃª posta suas coisas lÃ¡ no serviÃ§o de namoro.
As receptoras, bem, vocÃª sabe, de todos os 50 milhÃµes de mulheres que usam
aquele serviÃ§o de namoro, pode haver trÃªs deles que vÃ£o para esse serviÃ§o de namoro
serviÃ§o e dizer, ah, sim, Ã© exatamente isso que estou procurando.
Ele Ã© meio idiota.
Ele tem muito dinheiro.
Ele tem uma Ferrari.
Eu vou gostar daquele cara.
E entÃ£o vocÃªs dois se encontram atravÃ©s do serviÃ§o de namoro e inicialmente
vocÃªs nÃ£o podem conversar um com o outro, certo?
Inicialmente, o serviÃ§o de namoro diz, nÃ£o, vocÃª sabe, para garantir que esse cara
nÃ£o Ã© uma perseguidora e ela nÃ£o Ã© louca, vocÃª sabe, nÃ£o vamos deixar
vocÃªs trocam nÃºmeros de telefone, endereÃ§os e outras coisas.
VocÃª terÃ¡ que usar nosso sistema de chat e nosso sistema de e-mail para conversar
um para o outro. Mas, eventualmente, depois de vocÃª ter trocado mensagens atravÃ©s
o serviÃ§o de namoro, agora vocÃªs podem saber onde moram.
VocÃª pode trocar nÃºmeros de telefone e parar de usÃ¡-los.
VocÃª pode se comunicar diretamente.
Ã assim que funcionam os protocolos de modo esparso.
Com protocolos de modo esparso, vocÃª tem algum roteador em algum lugar
sua rede que funciona como aquela funcionalidade de serviÃ§o de namoro.
E assim os receptores, assim que o seu laptop enviar a mensagem IGMP para o roteador,
seu gateway padrÃ£o, seu gateway padrÃ£o diz, hmm, ok, eu sei que tenho
um receptor aqui, nÃ£o tenho ideia de onde estÃ¡ a fonte.
receptor deseja. Mas eu sei onde estÃ¡ o serviÃ§o de namoro nos termos
de um protocolo de roteamento multicast, esse serviÃ§o de namoro Ã© o que chamamos de
ponto de encontro, um RP.
EntÃ£o hÃ¡ algum roteador na rede que todos os roteadores rodando multicast
sei que esse cara Ã© o cara que procuramos.
Esse Ã© o ponto de encontro.
EntÃ£o agora seu roteador dirÃ¡, ok, vou criar algo chamado
uma junÃ§Ã£o, uma mensagem de junÃ§Ã£o multicast.
E vou enviÃ¡-lo na direÃ§Ã£o do ponto de encontro dizendo, ei,
Tenho um cara aqui que estÃ¡ procurando esse grupo.
E entÃ£o, eventualmente, essa junÃ§Ã£o chega ao ponto de encontro.
Agora a fonte pode ainda nÃ£o ter comeÃ§ado, mas o ponto de encontro agora
construiu um galho na Ã¡rvore desde o ponto de encontro atÃ©
esses roteadores atÃ© seu gateway padrÃ£o.
Agora abrimos um caminho para que, se o multicast comeÃ§ar, ele terÃ¡
uma direÃ§Ã£o em que ele possa fluir.
Agora a fonte, a fonte inicia, o servidor.
EntÃ£o esse servidor comeÃ§a a enviar seu multicast e atinge seu roteador,
algum roteador conectado a esse segmento, estÃ¡ sendo golpeado na parte traseira do
a cabeÃ§a com esse trÃ¡fego multicast.
Mais uma vez, aquele roteador lÃ¡ em cima, no outro canto da rede
diz, nunca tive notÃ­cias de nenhum receptor, mas sei onde estÃ¡ o namoro
serviÃ§o Ã©. Eu sei onde Ã© o ponto de encontro.
E entraremos em mais detalhes sobre isso, mas basicamente encapsula
em unicast. Ele pega aquele pacote multicast e o envolve dentro de um unicast
cabeÃ§alho e o envia para o ponto de encontro.
Assim que chega o ponto de encontro, ele desencapsula e diz, ah, aqui estÃ¡
multitransmissÃ£o. Ah, sim, eu sei onde isso vai porque recebi uma adesÃ£o
por isso e ele manda descer da Ã¡rvore.
EntÃ£o Ã© assim que nos protocolos de modo esparso inicialmente os conectamos, certo?
Esse ponto de encontro Ã© o serviÃ§o de encontros.
Mas, assim como na minha analogia, vocÃª nÃ£o quer que a fonte e o receptor
passando constantemente pelo ponto de encontro para conversar um com o outro.
NÃ£o Ã© necessariamente eficiente, certo?
E se o receptor estiver na FlÃ³rida, a fonte estiver na Carolina do Norte,
mas o ponto de encontro Ã© na CalifÃ³rnia?
Bem, nesse trÃ¢nsito estÃ¡ saindo do caminho para chegar ao ponto de encontro
apontar e voltar. HÃ¡ um caminho muito mais curto diretamente entre a fonte
e o receptor.
Mas tivemos que iniciar esse multicast antes de podermos descobrir
de onde vem, que vem da Carolina do Norte.
E agora os Rogers podem seguir esse caminho.
Eles podem dizer: OK, obrigado, serviÃ§o de encontros.
Obrigado, ponto de encontro.
NÃ£o preciso mais de vocÃª.
Agora sei exatamente onde estÃ¡ a fonte.
Podemos obter o trÃ¡fego diretamente dele e podemos mudar para isso
caminho. Portanto, esse Ã© um nÃ­vel realmente alto de como os protocolos de modo esparso funcionam.
Temos que nos juntar primeiro ao ponto de encontro, expressar o nosso interesse,
construir esse ramo.
O trÃ¡fego tem que comeÃ§ar a ir para o ponto de encontro e depois muda
acabou, entÃ£o vai diretamente entre a fonte e o receptor, ponto de encontro
ponto nem faz mais parte da equaÃ§Ã£o.
Portanto, os protocolos de modo esparso usam algo chamado Ã¡rvores baseadas em nÃºcleo ou Ã¡rvores RP
porque temos um ponto de encontro.
Portanto, o ponto de encontro Ã© o nÃºcleo da Ã¡rvore.
Todo mundo comeÃ§a indo atÃ© ele e entÃ£o se afasta dele muito
rapidamente. OK, entÃ£o RPF, caso vocÃª nÃ£o esteja familiarizado, Ã© claro, RPF poderia
mude para a Ã¡rvore.
SÃ£o muitas coisas diferentes, mas neste caso em particular significa
encaminhamento de caminho reverso.
Agora pense no trÃ¡fego unicast.
Vamos nos afastar do multicast por um segundo.
Um roteador recebe um pacote unicast indo para algum destino 9.9.9.9.
O que o roteador faz?
O roteador diz: OK, vou verificar o endereÃ§o IP de destino,
entre na minha tabela de roteamento e veja se tenho algum tipo de rota que diga
me onde fica esse destino.
Normalmente, para encaminhar esse pacote para colocÃ¡-lo a caminho,
o roteador se preocupa com a origem desse pacote?
NÃ£o, vocÃª nÃ£o estÃ¡ nem aÃ­ para qual Ã© o endereÃ§o de origem.
Na verdade, vocÃª poderia colocar 0, 0, 0, 0 como fonte, o roteador
nÃ£o me importaria. Para rotear esse pacote, tudo o que importa Ã© o
destino. Agora certamente vocÃª poderia implementar listas de acesso e outras
coisas assim para forÃ§Ã¡-lo a olhar para a fonte.
E vocÃª tambÃ©m pode implementar algo chamado RPF.
Por exemplo, e se eu, vocÃª sabe, digamos que meu laptop agora esteja parado
na rede 11, 11.alguma coisa, entÃ£o tive um endereÃ§o 11, 11.555.
Esse Ã© o endereÃ§o do meu laptop.
E eu descubro, descubro pelos boatos que vou ser
demitido hoje. Eu digo o que?
Cara, passei muitos anos nesta empresa.
Eu trabalhei horas extras.
Sacrifiquei meus filhos por esta empresa.
Eles vÃ£o me demitir.
Isso realmente me irrita.
EntÃ£o eu digo, quer saber?
Antes de ir, sei qual Ã© o endereÃ§o IP do servidor web da minha empresa.
Ã 77777. EntÃ£o, sou um pouco experiente o suficiente.
Eu digo, quer saber?
Vou derrubar esse servidor.
Vou atacar aquele servidor com, nÃ£o sei, algum tipo de trÃ¡fego.
Talvez solicitaÃ§Ãµes de sincronizaÃ§Ã£o TCP, certo?
Vou acabar com 5 milhÃµes de sincronizaÃ§Ãµes TCP a cada segundo.
Traz isso para baixo. EntÃ£o ha ha ha.
VocÃª quer me despedir?
Vou fazer vocÃªs perderem milhÃµes de dÃ³lares nos prÃ³ximos dois
de horas enquanto seu servidor estÃ¡ inativo.
Bem, se eu decidir fazer isso, nÃ£o quero que as pessoas rastreiem esses pacotes
de volta para mim, certo?
Porque nÃ£o sÃ³ serei despedido, como agora estarei numa cela com
alguÃ©m de quem nÃ£o gosto particularmente.
EntÃ£o eu nÃ£o quero isso.
EntÃ£o eu digo, hmm, se vou enviar essas solicitaÃ§Ãµes de sincronizaÃ§Ã£o TCP para esse servidor
para tentar sobrecarregÃ¡-lo, quero ter certeza de que o endereÃ§o de origem Ã©
eu nÃ£o. Eu nÃ£o quero ser 11555, que sou eu.
Quero falsificar esse endereÃ§o de origem para se parecer com outra coisa.
EntÃ£o, se encontrarem esses pacotes, nunca saberÃ£o que vieram de mim.
EntÃ£o, vou fornecer um endereÃ§o IP falso porque sei quando esses pacotes chegam
os roteadores, os roteadores nÃ£o se importam com o endereÃ§o de origem.
E vai falhar.
Bem, se eu sou o administrador da rede, uma coisa que posso fazer para evitar
pessoas fazendo isso Ã© que posso usar o que Ã© chamado de verificaÃ§Ã£o RPF unicast,
o que significa que quando um pacote entra em uma interface em um roteador, antes
Eu atÃ© olho o endereÃ§o de destino, vou olhar a origem
endereÃ§o, e vou me fazer uma pergunta muito simples.
Esse endereÃ§o de origem, se eu voltasse na direÃ§Ã£o inversa para
essa fonte, eu usaria essa interface onde ela acabou de entrar?
Agora estou sentado aqui.
Tenho 11.555. Alterei intencionalmente o endereÃ§o de origem do meu pacote
para algo completamente falso, como 12, 12, 12, 12.
Bem, ele veio nesta interface.
Chegou rÃ¡pido Ethan Ã s 00 no roteador.
De acordo com a tabela de roteamento deste roteador, diz ele, para chegar aos 12, 12
rede, eu nÃ£o iria rÃ¡pido Ethan Ã s 00.
Eu sairia da sÃ©rie 11.
Portanto, se esse administrador de rede configurou a verificaÃ§Ã£o RPF unicast
o roteador, o roteador dirÃ¡, hÃ¡ algo errado com este pacote.
De acordo com meu caminho inverso, eu nÃ£o seguiria esse caminho para chegar ao 12.
Eu iria por aqui.
O pacote veio na interface errada e seria descartado.
Seria descartado.
E agora meu servidor nunca receberia esse pacote.
Isso nunca prejudicaria o servidor.
Isso nÃ£o estÃ¡ ativado por padrÃ£o.
A verificaÃ§Ã£o Unicast RPF Ã© algo que vocÃª deve ativar se quiser fazer
que. Bem, como isso se relaciona com isso?
Quando vocÃª habilita o multicast, os protocolos de roteamento multicast fazem verificaÃ§Ãµes RPF em
a fonte por padrÃ£o.
Na verdade, vocÃª nÃ£o pode impedi-los de fazer isso.
Eles fazem isso. Agora, por que eles fazem isso?
Eles fazem isso para detecÃ§Ã£o de loop.
A ideia Ã© que quando um pacote multicast chega, vocÃª nÃ£o quer apenas circular
em torno da rede para sempre.
EntÃ£o o que os roteadores fazem Ã© dizer, ok, o roteador estÃ¡ rodando no modo esparso
protocolos. EntÃ£o, se eu sou um roteador conectado a uma rede, digamos que estou
o gateway padrÃ£o.
Sou o gateway conectado a este receptor, ao meu laptop aqui.
E acabei de ser informado via IGMP que este receptor deseja receber
algum multicast. 239-777.
Vamos apenas desenhar isso para deixar isso claro.
OK. EntÃ£o, aqui estÃ¡, oh, espere sÃ³ um segundo.
Vou fazer assim entÃ£o.
Aqui estÃ¡ meu receptor aqui como um quadrado.
Vamos colocar isso como um pequeno R.
E aqui estÃ¡ o gateway padrÃ£o ao qual ele estÃ¡ conectado.
Gateway padrÃ£o.
E ele tem vÃ¡rias interfaces que levam ao upstream.
Diremos apenas interface um, dois e trÃªs.
NÃ£o importa o que sejam.
Serial Ethernet rÃ¡pido, Ã© irrelevante para esta discussÃ£o.
Agora, este roteador acaba de receber um relatÃ³rio de associaÃ§Ã£o IGMP do
receptor. E esse receptor deseja obter o trÃ¡fego de 239-777.
Esse Ã© o grupo do qual ele quer participar.
Agora, este roteador estÃ¡ executando um protocolo de roteamento de modo esparso.
EntÃ£o, diremos apenas que Ã© PIM.
Ele estÃ¡ executando o protocolo de roteamento multicast independente de protocolo.
EntÃ£o, como parte do PIM, para fazer o PIM funcionar, ele diz, ok, eu sei
hÃ¡ algum roteador em algum lugar.
Chamaremos isso daqui, que Ã© meu ponto de encontro.
E entÃ£o eu tenho que avisar ao ponto de encontro que tenho um receptor
aqui embaixo quem quer isso.
EntÃ£o digamos que este ponto de encontro seja 8888.
EntÃ£o esse roteador, ele diz, ok, eu sei.
Vamos apenas fazer um pequeno balÃ£o de pensamento aqui.
Ele diz, eu sei que o PIM RP Ã© 8888.
Agora, ele diz, ok, como faÃ§o para chegar ao PIM RP?
Agora, Ã© aqui que ele usa seu protocolo de roteamento unicast.
JÃ¡ mencionei algumas vezes que o roteamento multicast funciona de mÃ£os dadas com
seu protocolo de roteamento unicast.
EntÃ£o ele diz, ok, deixe-me entrar na minha tabela de roteamento.
E de acordo com minha tabela de roteamento, tenho uma rota EI-JRP que diz
para chegar Ã rede 8.8 Ã© via interface 2.
EntÃ£o ele envia uma interface PIM join out 2.
E, eventualmente, essa junÃ§Ã£o do PIM percorre a rede e fica
atÃ© o ponto de encontro.
EntÃ£o esta Ã© agora a Ã¡rvore compartilhada, certo?
Esta Ã© a Ã¡rvore que vai do ponto de encontro atÃ© o gateway padrÃ£o.
Agora, este gateway padrÃ£o, porque ele estÃ¡ executando o modo escasso do PIMS, ele diz,
ok, espero que quando o multicast comeÃ§ar, sempre que comeÃ§ar,
deveria descer do ponto de encontro.
EntÃ£o, digamos que o multicast seja iniciado e aÃ­ vem.
Aqui desce desta forma.
Portanto a fonte Ã© 7777.
O destino Ã© 239.777.
Bem, como esse cara estÃ¡ executando o modo escasso do PIMS, ele faz uma verificaÃ§Ã£o de RPF.
Mas Ã© assim que funciona.
Ele diz, bem, porque eu esperava que esse multicast viesse atravÃ©s do
ponto de encontro, diz ele, em que interface deveria ter entrado?
Bem, de acordo com minha tabela de roteamento, para chegar ao ponto de encontro, eu
vÃ¡ pela interface 2.
Huh, este multicast nÃ£o saiu do ponto de encontro.
NÃ£o veio da interface 2.
EntÃ£o adivinhe? Eu vou matÃ¡-lo.
Esta Ã© uma falha de RPF.
NÃ£o desceu o que chamamos de Ã¡rvore compartilhada, a Ã¡rvore que Ã© compartilhada
entre o ponto de encontro e esse gateway padrÃ£o.
Apenas falhou na verificaÃ§Ã£o RPF.
Agora digamos que tenha acontecido desta forma.
Ok, entÃ£o veio pelo caminho correto.
A verificaÃ§Ã£o RPF seria bem-sucedida.
Isso passaria. Ele dizia, ok, estou interessado neste grupo, e isso aconteceu
entre na interface correta, na interface 2, que Ã© a interface
levando ao PR.
Agora algo interessante acontece.
EntÃ£o vamos em frente e colocar isso de volta aqui.
A origem foi 777. O destino foi 239.777.
Ok, entÃ£o ele pode encaminhar esse multicast para o cliente, para o receptor.
Agora, pela primeira vez, este roteador diz: ah, finalmente, eu sei quem
a fonte Ã©. O endereÃ§o real do servidor Ã© 777.
Agora PIMS-SPAR-SMO diz, ok, eu poderia continuar recebendo isso do encontro
ponto, mas existe um caminho melhor?
Existe realmente um caminho mais curto para chegar a essa fonte que seria mais
eficiente? EntÃ£o ele volta para sua tabela de roteamento.
Ele diz, ok, agora deixe-me fazer uma pesquisa RPF sobre isso.
E ele diz, ah, eis que tenho uma rota que corresponde a isso, a isso
Aprendi via EIGRP.
Mais uma vez, poderia ser aprendido via RIP ou OSPF.
NÃ³s nÃ£o nos importamos. Ele diz, isso Ã© via interface 1.
EntÃ£o agora o PIM faz algo especial.
Ele envia outro PIM para fora dessa maneira.
Vamos entrar em todos os detalhes disso.
E ele diz, isso Ã© para a origem 777 destino 239.777.
E essa junÃ§Ã£o do PIM vai atÃ© o fim.
E digamos que a fonte esteja bem aqui.
Na verdade, Ã© onde estÃ¡ o servidor.
E tem havido vÃ¡rios roteadores no meio.
EntÃ£o aqui estava um roteador.
Aqui estÃ¡ um roteador.
E aqui estÃ¡ um roteador.
E eles estÃ£o todos conectados assim.
Supondo que todos esses roteadores saibam como chegar Ã rede 777, isso
a junÃ§Ã£o especial do PIM teria subido atÃ© o fim e finalmente chegado
este roteador que estÃ¡ conectado Ã fonte.
E isso agora abriu a Ã¡rvore do caminho mais curto.
Observe que temos duas Ã¡rvores diferentes aqui.
Temos o azul e o verde.
E o ponto azul atÃ© o gateway padrÃ£o era chamado de Ã¡rvore compartilhada
ou Ã s vezes chamada de Ã¡rvore RP.
Ãs vezes vocÃª pode ver a sigla RPT.
Isso funcionou, mas pode nÃ£o ser o caminho mais eficiente.
Esta Ã¡rvore verde Ã© a Ã¡rvore do caminho mais curto.
Mas nÃ£o sabÃ­amos o que era isso atÃ© sabermos onde estava a fonte atÃ©
recebemos nosso primeiro pacote multicast.
E agora que abrimos aquela Ã¡rvore, o roteador diz, ok,
neste ponto, por um breve momento, na prÃ³xima vez que eu receber o multicast
pacote, ele pode vir de um de dois lugares.
Vou aceitÃ¡-lo na interface dois porque ainda pode vir de
o ponto de encontro.
E agora, se vier na interface um, tambÃ©m aceitarei porque
tentei abrir esse caminho.
Eu tentei intencionalmente abrir esse caminho esperando que o trÃ¡fego multicast
vai descer por aqui.
Portanto, agora, se o multicast vier na interface trÃªs, serÃ¡ uma falha de RPF.
Porque o roteador diz, ei, interface trÃªs, essa nÃ£o Ã© a Ã¡rvore compartilhada
e nÃ£o Ã© a Ã¡rvore do caminho mais curto.
Mas se um deles falhar, ele passarÃ¡ na verificaÃ§Ã£o do RPF.
E assim que o multicast realmente comeÃ§ar a fluir e entrar na interface
nÃºmero um, agora o gateway padrÃ£o dirÃ¡, Ã³timo!
Estou obtendo o trÃ¡fego multicast da maneira mais eficiente possÃ­vel
atravÃ©s da Ã¡rvore de caminho mais curto.
NÃ£o preciso mais tirÃ¡-lo do ponto de encontro.
EntÃ£o, ele enviarÃ¡ uma mensagem de remoÃ§Ã£o do PIM desta forma, que removerÃ¡
desta Ã¡rvore. E agora o multicast fluirÃ¡ pelo caminho mais curto
Ã¡rvore de caminhos atÃ© que o receptor nÃ£o a queira mais.
Portanto, esse Ã© um nÃ­vel muito alto de como funciona o modo esparso do PIM.
Mas fiz tudo isso para mostrar que as verificaÃ§Ãµes de RPF estÃ£o acontecendo.
Tudo depende de onde o roteador espera obter o multicast.
Se ele espera que isso venha do ponto de encontro, ele vai
digamos, olhe, o ponto de encontro fica na interface um ou na interface sete,
e ele aprende isso por meio de seu protocolo de roteamento.
Ã aÃ­ que espero obter o multicast inicialmente.
Se vier de qualquer outra interface, vou eliminÃ¡-lo.
Eu vou largar isso.
NÃ£o era para acontecer assim.
Mas uma vez que ele sabe qual Ã© a fonte e tenta abrir o caminho mais curto
Ã¡rvore de caminho, agora o RPF terÃ¡ sucesso.
Ele serÃ¡ aprovado se o multicast descer pela Ã¡rvore de caminho mais curto.
EntÃ£o, como determinamos a interface de entrada correta?
Como podemos ter certeza de que o RPF foi bem-sucedido ou aprovado com base no tipo
de Ã¡rvore que estamos esperando?
SerÃ¡ que estamos esperando que ela desÃ§a pela Ã¡rvore central, tambÃ©m conhecida como
Ãrvore RP? Ou esperamos que o trÃ¡fego desÃ§a pela Ã¡rvore de origem?
Agora, pode depender do tipo especÃ­fico de IGP.
Do que estou falando aÃ­?
O PIM nÃ£o Ã© o Ãºnico protocolo de roteamento multicast.
Existem outros.
Por exemplo, MOSPF, OSPF multicast.
VocÃª provavelmente pode adivinhar se estou usando OSPF multicast para descobrir
descobrir qual Ã© a interface correta para ir para o RP, ou a interface correta
para ir atÃ© a origem, ele depende de rotas OSPF.
O MOSPF nÃ£o pode fazer a verificaÃ§Ã£o RPF com base em RIP ou EIGRP.
Precisa de OSPF. HÃ¡ outro chamado DVMRP, Distance Vector Multicast
Protocolo de roteamento.
Esse Ã© meio estranho.
Na verdade, ele cria sua prÃ³pria tabela unicast separada apenas para fazer verificaÃ§Ãµes de RPF.
A tabela DVMRP.
NÃ£o usa mais nada.
O que hÃ¡ de maravilhoso no PIM, Protocol Independent Multicast.
O Protocolo Independente significa que o PIM diz, nÃ£o me importo.
Quando faÃ§o uma verificaÃ§Ã£o RPF, irei para a tabela de roteamento.
NÃ£o me importo se consigo encontrar uma rota que seja estÃ¡tica, rota conectada,
EIGRP, RIP, OSPF.
Eu nÃ£o ligo. Contanto que eu encontre algo para fazer minha verificaÃ§Ã£o de RPF,
Eu vou ser feliz. Ã por isso que o PIM Ã© tÃ£o popular porque permite que vocÃª use
qualquer protocolo de roteamento IGP que vocÃª desejar.
NÃ£o depende disso.