EntÃ£o, atÃ© este momento nos vÃ­deos anteriores, falamos sobre
como a Ã¡rvore compartilhada Ã© construÃ­da, atÃ© o ponto de encontro e
entÃ£o parando por aÃ­.
E entÃ£o o Ãºltimo vÃ­deo sobre o qual falamos, ok, uma vez que aquela fonte, aquela
servidor, comeÃ§a a enviar seu trÃ¡fego multicast, o primeiro roteador
estÃ¡ conectado, que vocÃª consideraria o gateway padrÃ£o para o
fonte, pegarÃ¡ esses pacotes multicast e os registrarÃ¡ no PIM
ponto de encontro.
E falamos sobre como isso basicamente leva os pacotes multicast
e agrupÃ¡-los dentro de um cabeÃ§alho PIM e depois agrupÃ¡-los dentro
de um cabeÃ§alho IP unicast do roteador para o RP.
EntÃ£o agora vamos ver como juntar a Ã¡rvore do caminho mais curto.
Agora lembre-se, mencionei isso no outro vÃ­deo que cada roteador tem seu
prÃ³pria perspectiva sobre qual Ã© a Ã¡rvore do caminho mais curto, certo?
Assim que um roteador recebe um pacote multicast, de repente ele tem
esse despertar diz aha, isso Ã© o que eu estava procurando e agora
ConheÃ§o o componente crÃ­tico que nÃ£o conhecia antes.
Eu sei quem Ã© a fonte.
EntÃ£o aquele roteador, com licenÃ§a, entÃ£o nÃ£o faz RP para cima.
Ele entra na tabela de roteamento unicast e diz, para mim, qual Ã© o caminho mais curto
caminho de volta para essa fonte?
Agora, isso pode levar vocÃª a fazer a pergunta, ok, isso significa que
em qualquer lugar ao longo da Ã¡rvore, desde a fonte atÃ© o receptor,
se houver alguma ramificaÃ§Ã£o em qualquer lugar que se ramifique e seja realmente mais curta
caminho, isso significa que qualquer roteador em qualquer lugar ao longo desse caminho Ã© permitido
para mudar para a Ã¡rvore de caminho mais curto e sair dessa Ã¡rvore central e
sair da Ã¡rvore de pontos de encontro?
NÃ£o exatamente. E entÃ£o vamos falar sobre isso aqui.
Mas nesta situaÃ§Ã£o particular, o ponto de encontro tem permissÃ£o
fazer isso porque lembre-se, neste momento, o ponto de encontro estÃ¡ recebendo
registrar pacotes, o que estÃ¡ fazendo com que sua CPU trabalhe um pouco mais
do que deveria. Normalmente, o que realmente queremos Ã© quando um pacote multicast
entra, queremos apenas procurar a entrada na tabela mRout e encaminhar
estÃ¡ a caminho. Na verdade, se vocÃª estiver executando o SEP, o Cisco Express
Encaminhamento, vocÃª pode atÃ© fazer tudo isso sem potencialmente interromper
a CPU, como por exemplo, em switches.
Se vocÃª tiver um switch multicamada com T cams e encaminhamento A6 e encaminhamento
motores e outras coisas, a CPU e o switch estÃ£o fazendo todo o processamento do PIM.
EntÃ£o, quando vocÃª junta PIM, poda PIM, registra pacotes PIM, eles precisam
vÃ¡ atÃ© a CPU para ser processado.
EntÃ£o, se aquele switch multicamadas, que funciona como um roteador,
estÃ¡ recebendo toneladas de pacotes de registro, tudo isso indo para uma CPU.
Considerando que se isso estivesse chegando como multicast nativo, tudo isso poderia
ser manipulado em hardware em suas cÃ¢meras T e A6 e outras coisas e isso seria
nunca incomode a CPU, nunca seja visto pela CPU.
EntÃ£o, idealmente, Ã© isso que queremos.
EntÃ£o, queremos interromper esse processo de registro o mais rÃ¡pido possÃ­vel para que possamos
nÃ£o precisa fazer todo esse trabalho extra.
EntÃ£o mencionamos que a forma como isso vai acontecer Ã© que o PIM
RP enviarÃ¡ uma mensagem de junÃ§Ã£o chamada s, g join upstream para abrir
seguir seu prÃ³prio caminho mais curto.
E essa Ã© a maneira dele de dizer, ok, quero abrir para que o multicast
pode fluir em sua forma nativa.
Assim que isso comeÃ§ar a acontecer e eu ver isso, eu confirmei isso, entÃ£o o
RP diz para parar o registro.
Eu nÃ£o quero mais isso.
Pare de fazer o processo de cadastro e ele realmente envia um cadastro PIM
parar. NÃ³s conversamos sobre isso.
Agora, eu sei que tambÃ©m neste caso especÃ­fico, R2 estÃ¡ se juntando ao caminho mais curto
Ã¡rvore de caminho. Agora, deixe-me voltar ao meu desenho original aqui por um momento.
Ã assim que Ã© nossa topologia atual.
Agora, eu sei que projetei isso intencionalmente para que o R8 pudesse
para chegar diretamente ao roteador quatro sem ir ao roteador trÃªs.
EntÃ£o, alguÃ©m poderia olhar para isso e dizer, ok, entÃ£o eu presumiria que quando
o primeiro pacote multicast, quando o primeiro pacote de registro, o primeiro
o pacote de registro vem downstream para o roteador trÃªs e o roteador trÃªs Ã© encapsulado
isso e envia-o como um multicast nativo para o roteador oito, nÃ£o apenas
o roteador trÃªs enviaria sua junÃ§Ã£o upstream tentando ingressar em seu caminho mais curto
Ã¡rvore de caminhos, nÃ£o esperarÃ­amos que o roteador oito fizesse isso tambÃ©m?
Quero dizer, afinal, o roteador oito agora sabe quem Ã© a fonte e deveria
olhe em sua tabela de roteamento e diga, ah, espere, consegui essa conexÃ£o direta BAM
aqui atÃ© a fonte.
Esse Ã© o meu caminho mais curto.
NÃ£o esperarÃ­amos que ele tambÃ©m se juntasse Ã Ã¡rvore do caminho mais curto?
Bem, vamos dar uma olhada nisso em um rastreamento de farejador.
Direi exatamente o que diz a RFC.
A RFC para o modo escasso do PIMS diz que as Ãºnicas pessoas que tÃªm permissÃ£o
para mudar de uma Ã¡rvore compartilhada para uma Ã¡rvore de caminho mais curto sÃ£o nÃºmeros
um, o ponto de encontro, como falamos, ou o Ãºltimo
roteador de salto. Em outras palavras, o roteador que estÃ¡ diretamente conectado ao
receptor. EntÃ£o, de acordo com a RFC, neste diagrama especÃ­fico, roteador
oito nÃ£o seriam autorizados a iniciar esse processo.
Ele teria que receber o multicast na Ã¡rvore compartilhada e entÃ£o
continue a passÃ¡-lo downstream para o roteador dois.
E como o roteador dois estÃ¡ diretamente conectado ao receptor, lembre-se:
vimos isso com uma pequena bandeira C porque ele recebeu o relatÃ³rio de sÃ³cios,
isso significa que seria sua responsabilidade conectar-se ao caminho mais curto
Ã¡rvore de caminhos, nÃ£o Ã© responsabilidade do roteador oito.
EntÃ£o, vamos dar uma olhada nisso em um rastreamento de farejador e ver se isso Ã©
verdade porque sabemos que Ã s vezes com roteadores Cisco e outras coisas, eles
nÃ£o siga exatamente a RFC.
EntÃ£o vamos ver se isso vai acontecer.
Mas antes de fazermos isso, nÃ£o quero avanÃ§ar aqui.
E a propÃ³sito, este roteador dois na RFC, vocÃª pode vÃª-lo no termo dois
Coisa diferente.
Eu jÃ¡ o vi chamado roteador de Ãºltimo salto e tambÃ©m o vi denominado folha
roteadores. Ã como uma folha na ponta da Ã¡rvore.
Vai, a Ã¡rvore nÃ£o vai alÃ©m disso.
EntÃ£o eles chamarÃ£o roteadores leaf ou roteadores de Ãºltimo salto.
Ok, entÃ£o esta Ã© uma revisÃ£o do que jÃ¡ falamos.
EntÃ£o nÃ£o preciso entrar lÃ¡.
E mencionei como as junÃ§Ãµes S, G sÃ£o usadas para abrir o caminho mais curto
Ã¡rvore. E vocÃª verÃ¡ aquela sigla S P T o tempo todo ao falar sobre
PIM, Ã¡rvore de caminho mais curto.
EntÃ£o, o que desencadeia uma junÃ§Ã£o S, G?
Bem, mais uma vez hÃ¡ vÃ¡rias coisas que podem desencadear isso.
Se acontecer de vocÃª ser o ponto de encontro e receber um pacote multicast
e um registro, que farÃ¡ com que vocÃª envie uma junÃ§Ã£o S, G.
Porque como ponto de encontro, vocÃª vai querer abrir o seu caminho mais curto
caminho. EntÃ£o isso Ã© uma coisa que pode desencadear isso.
O que Ã© outra coisa?
Como falamos, se vocÃª for um roteador leaf quando receber o multicast
pacote. Agora, isso tambÃ©m levanta um ponto interessante.
EntÃ£o vocÃª pode estar se perguntando, bem, o roteador leaf faz isso imediatamente?
SÃ³ depois ele recebe 10 pacotes ou recebe alguns bits por segundo.
VocÃª sabe, quando o roteador leaf decide fazer isso?
A RFC real nÃ£o define isso.
A RFC real para PIMS Farsmo apenas diz que o roteador leaf pode, ele nÃ£o
ainda tem que fazer isso.
O roteador leaf pode mudar para a Ã¡rvore de caminho mais curto uma vez determinado
limite Ã© atingido.
Isso Ã© tudo que diz.
Agora, como os roteadores Cisco realmente fazem isso?
O limite para roteadores Cisco Ã© um pacote, apenas um.
EntÃ£o, quando o primeiro pacote multicast atinge o roteador dois e o roteador
dois primeiro aprende qual Ã© o endereÃ§o de origem, esse Ã© o seu gatilho
para dizer, ok, eu tenho um caminho mais curto?
Deixe-me participar. EntÃ£o esse Ã© o limite nos roteadores Cisco.
Agora vocÃª pode perguntar: tenho outra opÃ§Ã£o?
HÃ¡ algo mais que eu possa fazer?
Deixe-me mostrar qual Ã© o comando para modificar esse comportamento.
VocÃª nÃ£o tem muitas opÃ§Ãµes.
Na verdade, sÃ£o apenas dois.
Apenas duas opÃ§Ãµes estÃ£o disponÃ­veis para vocÃª.
EntÃ£o vou usar o roteador leaf aqui.
E o comando Ã© IP PIM.
E entÃ£o Ã© o limite do SPT.
Portanto, o limite do caminho Shores.
E vocÃª sÃ³ tem duas opÃ§Ãµes.
Zero, que Ã© o padrÃ£o, ou infinito, o que significa nunca mudar
para o caminho mais curto.
Ã isso. Nada no meio.
Assim, vocÃª pode decidir por si mesmo em que circunstÃ¢ncias deseja
para selecionar o infinito.
Mas o padrÃ£o Ã© alternar assim que vocÃª receber o primeiro pacote.
Que estado eles criam na tabela de rotas M?
Ok, entÃ£o se eu voltar para o meu roteador aqui, vamos usar isso
cara. Mostrar rota IP M.
Ok, atÃ© agora temos nossa entrada com estrela e vÃ­rgula G.
Agora, a entrada estrela e vÃ­rgula G Ã© construÃ­da com base na Ã¡rvore compartilhada.
Onde a Ãºnica coisa que sabemos Ã© o ponto de encontro.
E como chegar ao ponto de encontro.
Portanto, se os pacotes multicast comeÃ§arem a fluir pela Ã¡rvore compartilhada, este Ã© o
construÃ§Ã£o que usaremos para encaminhar esses pacotes multicast.
Agora vocÃª diz, bem, se o multicast realmente comeÃ§ar a fluir e nÃ³s agora
conhecemos a fonte, tambÃ©m vamos usar isso?
Bem, veja algumas coisas aqui.
NÃºmero um, interface de entrada.
Um vizinho RPF.
Tudo isto se baseia no nosso conhecimento do ponto de encontro.
Se eu estiver realmente recebendo dados multicast reais, isso nÃ£o seria relevante,
certo? Porque a interface de entrada e o vizinho RPF para chegar ao
a prÃ³pria fonte real pode nÃ£o ser esta.
Pode ser algo diferente.
AlÃ©m disso, eu nÃ£o precisaria mais de uma estrela aqui porque agora eu saberia o que
o endereÃ§o de origem Ã©.
Assim, no momento em que um roteador recebe o primeiro pacote multicast,
ele cria uma segunda entrada aqui, que Ã© chamada de entrada S, vÃ­rgula G.
EntÃ£o vamos em frente e fazer isso.
Vamos comeÃ§ar pelo fluxo.
Basicamente, faÃ§a meu ping novamente.
OK. E na verdade eu tenho que ir para o roteador oito porque durante o intervalo,
Eu adicionei algo aqui que poderia estragar nossa demonstraÃ§Ã£o.
EntÃ£o, eu sÃ³ quero me livrar disso.
Ok, entÃ£o vamos dar uma olhada aqui no roteador dois agora.
Mostrar IP, rota M.
EntÃ£o aqui vemos o que Ã© chamado de entrada de rota S, vÃ­rgula G, M.
S porque, ei, nÃ³s realmente sabemos quem Ã© a fonte ali.
Portanto, a interface de entrada e o vizinho RPF sÃ£o realmente relevantes agora
para a fonte, nÃ£o para o ponto de encontro.
Agora, minha topologia especÃ­fica, eu realmente fiz isso para que em R2, ele
prefira esse link serial para chegar ao R4 em vez desses links Ethernet rÃ¡pidos.
Acabei de fazer isso manipulando o EIGRP e usando listas de deslocamento e outras coisas
assim. Mas R2 diz ok, para chegar Ã rede quatro cinco, esta Ã©
o caminho preferido.
E mais uma vez, posso apenas verificar isso, mostrar IP RPF, quatro ponto cinco ponto
quatro ponto cinco. E diz, prefiro usar serial zero um zero, e
isso Ã© via EIGRP 100.
EntÃ£o Ã© isso que usamos como interface de entrada.
E o vizinho RPF Ã©, bem, como parece, o prÃ³ximo vizinho importante a ir
nessa direÃ§Ã£o.
Agora, quando hÃ¡ muitas regras em torno disso, temos que seguir.
EntÃ£o, nÃºmero um, quando um S, vÃ­rgula G Ã© formado pela primeira vez, basicamente leva
o que quer que esteja na lista de interface de saÃ­da da estrela, vÃ­rgula G, e apenas
copia aqui embaixo.
EntÃ£o normalmente eles sÃ£o iguais.
HÃ¡ uma circunstÃ¢ncia em que isso nÃ£o vai acontecer.
Existe uma regra de PIM, e isso realmente existe tanto para a estrela, vÃ­rgula
G e o S, vÃ­rgula G, que diz que vocÃª nunca poderÃ¡ ter sua interface de entrada
na lista de interfaces de saÃ­da.
Em outras palavras, sua interface de entrada nÃ£o pode ser igual Ã de saÃ­da.
interface. EntÃ£o, se vocÃª vir nulo na lista de interfaces de saÃ­da, o que significa
nada, pode ser por isso.
Mas neste caso, nÃ£o precisamos nos preocupar com isso.
EntÃ£o a interface de entrada Ã© serial zero um zero, e ele apenas copiou
isso aqui embaixo. Ok, o que significa o J?
A bandeira J significa que enviei uma junÃ§Ã£o nesta direÃ§Ã£o.
Portanto, neste caso especÃ­fico, como esta Ã© a Ã¡rvore do caminho mais curto, isso
significa que enviei um S, vÃ­rgula G para juntar-se Ã Ã¡rvore do caminho mais curto.
Agora, a bandeira J por si sÃ³ nÃ£o Ã© prova de que realmente recebemos qualquer
dados multicast daquela direÃ§Ã£o.
Tudo o que isso significa Ã© que tentamos abrir essa direÃ§Ã£o.
O que normalmente gostarÃ­amos de ver depois da bandeira J, e vou
investigue isso aqui, seria a bandeira T.
Normalmente verÃ­amos a bandeira T depois da bandeira J, e a bandeira T na verdade
significa que recebi dados multicast reais da Ã¡rvore de caminho mais curto.
Agora, por que nÃ£o estamos vendo isso neste caso especÃ­fico?
Bem, vamos solucionar um pouco aqui.
Sabemos que para receber trÃ¡fego multicast nesta direÃ§Ã£o,
precisamos ter PIM bem aqui.
Ok, entÃ£o pergunta nÃºmero um, o roteador dois tem um vizinho PIM na serial
zero um zero? Se ele tem um vizinho PIM, entÃ£o isso Ã© prova de que realmente
habilitei o PIM no roteador quatro.
EntÃ£o vamos ver, mostre o vizinho IP PIM.
E ele nÃ£o.
Tudo bem, entÃ£o sÃ³ temos um vizinho no rÃ¡pido Ethan no zero um.
NÃ£o temos na serial, por isso nÃ£o estamos recebendo trÃ¡fego
dessa maneira. EntÃ£o, vamos dar uma olhada no roteador quatro.
Sim, e Peter sÃ³ para validar, vocÃª realmente precisa ver a bandeira T em
esta entrada aqui para verificar se vocÃª recebeu trÃ¡fego multicast inativo
a Ã¡rvore do caminho mais curto.
Tudo o que a bandeira J significa Ã© que tentei entrar naquela Ã¡rvore, mas nÃ£o conseguimos.
saiba se jÃ¡ estÃ¡ funcionando.
E este caso em particular claramente nÃ£o estÃ¡ funcionando porque eu nem tenho
um vizinho nessa interface.
EntÃ£o por que nÃ£o? Vamos para o roteador quatro.
Mostrar interface de execuÃ§Ã£o serial zero um zero.
E lÃ¡ vamos nÃ³s.
NÃ£o habilitei o PIM nessa interface.
EntÃ£o isso explica isso.
Ok, o ping ainda estÃ¡ ativo ou jÃ¡ foi feito?
Sim, ainda estou indo.
EntÃ£o agora vamos para o roteador dois.
E lÃ¡ vamos nÃ³s.
Agora temos a bandeira T.
Isso Ã© bom. Isso significa que comeÃ§amos a receber mensagens multicast
trÃ¡fego da Ã¡rvore de caminho mais curto.
OK. E sÃ³ para o caso de vocÃª estar assistindo esta gravaÃ§Ã£o e
vocÃª pulou a seÃ§Ã£o anterior sobre registros PIM, naquele particular
seÃ§Ã£o eu fiz um rastreamento de um PIM S, vamos dar uma olhada nisso
realmente rÃ¡pido. EntÃ£o Ã© assim que se parece uma junÃ§Ã£o S, G.
Ele ainda sai como multicast usando o mesmo endereÃ§o de destino PIM
de 2240013. EntÃ£o Ã© salto por salto.
Portanto, o endereÃ§o de origem mudarÃ¡ salto a salto.
E no corpo da mensagem PIM estÃ¡ o tipo trÃªs, mais uma vez, junte-se
ameixa seca. Vizinho de cima, para quem isso vai?
Para quem Ã© meu vizinho RPF para quem estou enviando isso?
E dirÃ¡, nÃºmero de junÃ§Ãµes, em quantos grupos estou participando?
EntÃ£o, o que realmente diferencia uma junÃ§Ã£o estrela, G de uma junÃ§Ã£o S, G sÃ£o as
bandeiras aqui.
Vimos na estrela G juntar que alÃ©m do bit S, tÃ­nhamos o W
bit e o bit R.
O bit W era o curinga, o que significa que nÃ£o sei qual Ã© a fonte
do fluxo Ã©.
EntÃ£o este endereÃ§o IP, se o W estivesse aqui, isso significaria este endereÃ§o IP
Ã© o ponto de encontro.
Mas com base no fato de que o W estÃ¡ faltando, isso significa que isso Ã© realmente
o endereÃ§o IP da origem do prÃ³prio fluxo.
AlÃ©m disso, o bit R estÃ¡ faltando.
O bit R Ã© chamado de bit RP.
Se vocÃª realmente olhar na especificaÃ§Ã£o PIM, ela Ã© chamada de bit RP.
E isso significaria que esta mensagem, seja uma ameixa ou uma junÃ§Ã£o, vai
subir na Ã¡rvore RP. EstÃ¡ subindo na Ã¡rvore compartilhada em direÃ§Ã£o ao ponto de encontro.
Mais uma vez, isso estÃ¡ faltando aqui, porque isso nÃ£o vai subir no compartilhamento
Ã¡rvore. Isso estÃ¡ destinado a subir na Ã¡rvore do caminho mais curto.
Fora isso, eles parecem fundamentalmente iguais, uma estrela, G junta-se e
uma junÃ§Ã£o S, G. O corpo parece o mesmo.
VocÃª realmente tem que olhar as bandeiras aqui para ver.
O W no bit R estÃ¡ aqui ou estÃ¡ faltando?
Ã isso que diferencia os dois.
Agora, mencionei que uma das coisas que poderia causar o estado S, G em
o roteador Ã© se vocÃª estiver realmente recebendo o prÃ³prio trÃ¡fego multicast.
HÃ¡ outra situaÃ§Ã£o que pode causar isso.
Se vocÃª receber uma junÃ§Ã£o S, G de um roteador downstream, por exemplo, vamos
nÃ£o use este.
Digamos, por exemplo, que temos esta situaÃ§Ã£o.
Esse cara Ã© o RP.
Chamaremos esse cara de roteador um, roteador dois e roteador trÃªs.
Colocaremos nosso receptor aqui e colocaremos nossa fonte aqui.
Tudo bem, entÃ£o sabemos que inicialmente, assim que o multicast comeÃ§ar
fluindo, irÃ¡ nesta direÃ§Ã£o atÃ© o ponto de encontro, descendo
a Ã¡rvore compartilhada e depois para o receptor.
EntÃ£o, neste momento, o roteador dois nÃ£o tem nenhum estado.
Ele nÃ£o tem estado de rota M para o fluxo.
NinguÃ©m nunca pediu isso a ele, seja IGMP ou PIM.
EntÃ£o, se ele mostrasse a rota do IPM, nÃ£o verÃ­amos nada.
Nada relacionado ao fluxo.
Mas quando o roteador um estÃ¡ tentando ingressar no caminho mais curto, se presumirmos
que este Ã© o caminho mais curto, ele enviarÃ¡ um PIM S, G join upstream.
E como vimos no corpo da mensagem, ele dirÃ¡ roteador vizinho
dois, o endereÃ§o IP do roteador dois, e entÃ£o ele fornecerÃ¡ a origem e o destino,
certo? Ele darÃ¡ a origem do fluxo.
Digamos apenas que isso Ã© xxx.
Ele terÃ¡ aqui fonte igual a xxx, grupo igual, vocÃª sabe, tanto faz
isso Ã©. Portanto, agora, embora o roteador dois inicialmente nÃ£o tivesse estado de rota M em
tudo, uma vez que ele obtenha essa junÃ§Ã£o S, G, isso criarÃ¡ o estado S, G
em sua tabela de rotas M.
E entÃ£o ele poderÃ¡ criar sua prÃ³pria junÃ§Ã£o S, G e enviÃ¡-la
Por aqui. Um outro componente chave, vocÃª pode ser testado em alguns