Como funciona o protocolo PIM

O protocolo PIM é um conjunto de protocolos para transmissão multicast em uma rede entre roteadores. Os relacionamentos de vizinhança são construídos da mesma forma que no caso dos protocolos de roteamento dinâmico. O PIMv2 envia mensagens Hello a cada 30 segundos para o endereço multicast reservado 224.0.0.13 (All-PIM-Routers). A mensagem contém Hold Timers - geralmente igual a 3.5*Hello Timer, ou seja, 105 segundos por padrão.

O PIM usa dois modos de operação principais - modo Denso e Esparso. Vamos começar com o modo Denso.
Árvores de distribuição baseadas na fonte.
O modo de modo denso é aconselhável para uso no caso de um grande número de clientes de diferentes grupos multicast. Quando um roteador recebe tráfego multicast, a primeira coisa que ele faz é verificar a regra RPF. RPF - esta regra é usada para verificar a origem de um multicast com uma tabela de roteamento unicast. É necessário que o tráfego chegue à interface atrás da qual este host está oculto de acordo com a versão da tabela de roteamento unicast. Este mecanismo resolve o problema de ocorrência de um loop durante a transmissão multicast.

R3 reconhecerá a fonte multicast (IP de origem) da mensagem multicast e verificará os dois fluxos de R1 e R2 usando sua tabela unicast. O fluxo da interface apontada pela tabela (R1 a R3) será transmitido posteriormente, e o fluxo de R2 será descartado, pois para chegar à fonte multicast é necessário enviar pacotes via S0/1.
A questão é: o que acontece se você tiver duas rotas equivalentes com a mesma métrica? Neste caso, o roteador selecionará o próximo salto dessas rotas. Quem tiver o endereço IP mais alto vence. Se precisar alterar esse comportamento, você poderá usar o ECMP. Mais detalhes aqui.
Após verificar a regra RPF, o roteador envia um pacote multicast para todos os seus vizinhos PIM, exceto aquele de quem o pacote foi recebido. Outros roteadores PIM repetem esse processo. O caminho que um pacote multicast percorreu da origem até os destinatários finais forma uma árvore chamada árvore de distribuição baseada na origem, árvore de caminho mais curto (SPT), árvore de origem. Três nomes diferentes, escolha qualquer um.
Como resolver o problema de alguns roteadores não desistirem de algum stream multicast e não ter para quem enviar, mas o roteador upstream envia para ele. O mecanismo Prune foi inventado para isso.
Mensagem de poda.
Por exemplo, R2 continuará a enviar um multicast para R3, embora R3, de acordo com a regra RPF, o descarte. Por que carregar o canal? R3 envia uma mensagem PIM Prune e R2, ao receber esta mensagem, removerá a interface S0/1 da lista de interfaces de saída para este fluxo, a lista de interfaces das quais este tráfego deve ser enviado.

A seguir está uma definição mais formal de uma mensagem PIM Prune:
A mensagem PIM Prune é enviada por um roteador para um segundo roteador para fazer com que o segundo roteador remova o link no qual o Prune é recebido de um SPT (S,G) específico.

Depois de receber a mensagem Prune, R2 define o temporizador Prune para 3 minutos. Após três minutos, ele começará a enviar tráfego novamente até receber outra mensagem do Prune. Isso está no PIMv1.
E no PIMv2 foi adicionado um temporizador de atualização de estado (60 segundos por padrão). Assim que uma mensagem Prune for enviada do R3, este temporizador será iniciado no R3. Após a expiração deste temporizador, R3 enviará uma mensagem de atualização de estado, que redefinirá o temporizador de remoção de 3 minutos em R2 para este grupo.
Razões para enviar uma mensagem Prune:

• Quando um pacote multicast falha na verificação RPF.
• Quando não há clientes conectados localmente que tenham solicitado um grupo multicast (IGMP Join) e não há vizinhos PIM para os quais o tráfego multicast possa ser enviado (Non-prune Interface).

Mensagem de enxerto.
Vamos imaginar que R3 não queria tráfego de R2, enviou Prune e recebeu um multicast de R1. Mas, de repente, o canal entre R1-R3 caiu e R3 ficou sem multicast. Você pode esperar 3 minutos até que o Prune Timer em R2 expire. 3 minutos é uma longa espera, para não esperar, você precisa enviar uma mensagem que trará instantaneamente esta interface S0/1 para R2 fora do estado podado. Esta mensagem será uma mensagem Enxertada. Após receber a mensagem Graft, R2 responderá com um Graft-ACK.
Substituição de remoção.

Vejamos este diagrama. R1 transmite multicast para um segmento com dois roteadores. R3 recebe e transmite tráfego, R2 recebe, mas não tem ninguém para quem transmitir tráfego. Ele envia uma mensagem Prune para R1 neste segmento. R1 deveria retirar Fa0/0 da lista e parar de transmitir neste segmento, mas o que acontecerá com R3? E o R3 está no mesmo segmento, também recebeu essa mensagem do Prune e entendeu a tragédia da situação. Antes de R1 interromper a transmissão, ele define um cronômetro de 3 segundos e interromperá a transmissão após 3 segundos. 3 segundos - é exatamente quanto tempo R3 tem para não perder seu multicast. Portanto, R3 envia uma mensagem Pim Join para este grupo o mais rápido possível, e R1 não pensa mais em interromper a transmissão. Sobre Junte-se às mensagens abaixo.
Afirmar mensagem.

Vamos imaginar esta situação: dois roteadores transmitem para uma rede ao mesmo tempo. Eles recebem o mesmo fluxo da fonte e ambos o transmitem para a mesma rede por trás da interface e0. Portanto, eles precisam determinar quem será o único emissor desta rede. Mensagens de afirmação são usadas para isso. Quando R2 e R3 detectam duplicação de tráfego multicast, ou seja, R2 e R3 recebem um multicast que eles próprios transmitem, os roteadores entendem que algo está errado aqui. Neste caso, os roteadores enviam mensagens Assert, que incluem a Distância Administrativa e a métrica da rota com a qual a origem do multicast é alcançada - 10.1.1.10. O vencedor é determinado da seguinte forma:

1. Aquele com menor AD.
2. Se AD forem iguais, então quem tem a métrica mais baixa.
3. Se aqui houver igualdade, então quem tem o IP maior na rede para a qual transmite esse multicast.

O vencedor desta votação se torna o Roteador Designado. Pim Hello também é usado para selecionar DRs. No início do artigo foi mostrada a mensagem PIM Hello, você pode ver o campo DR ali. Ganha aquele que tiver o endereço IP mais alto neste link.
Sinal útil:

Tabela MROUTE.
Após uma primeira olhada em como funciona o protocolo PIM, precisamos entender como trabalhar com uma tabela de roteamento multicast. A tabela mroute armazena informações sobre quais fluxos foram solicitados pelos clientes e quais fluxos estão fluindo dos servidores multicast.
Por exemplo, quando um Relatório de Associação IGMP ou Junção PIM é recebido em alguma interface, um registro do tipo ( *, G ) é adicionado à tabela de roteamento:

Esta entrada significa que foi recebido um pedido de tráfego com o endereço 238.38.38.38. A flag DC significa que o multicast irá operar em modo Denso e C significa que o destinatário está conectado diretamente ao roteador, ou seja, o roteador recebeu o IGMP Membership Report e o PIM Join.
Se houver um registro do tipo (S,G) significa que temos um stream multicast:

No campo S - 192.168.1.11, cadastramos o endereço IP da fonte multicast, é este que será verificado pela regra RPF. Se houver problemas, a primeira coisa que você precisa fazer é verificar a tabela unicast para saber a rota até a origem. No campo Incoming Interface, indica a interface na qual o multicast é recebido. Em uma tabela de roteamento unicast, a rota para a origem deve referir-se à interface especificada aqui. A interface de saída especifica para onde o multicast será redirecionado. Se estiver vazio, o roteador não recebeu nenhuma solicitação para esse tráfego. Mais informações sobre todas as bandeiras podem ser encontradas aqui.
Modo PIM esparso.
A estratégia do modo esparso é o oposto do modo denso. Quando o modo esparso recebe tráfego multicast, ele enviará tráfego apenas através das interfaces onde houve solicitações para esse fluxo, por exemplo, mensagens Pim Join ou IGMP Report solicitando esse tráfego.
Elementos semelhantes para SM e DM:

• As relações de vizinhança são construídas da mesma forma que no PIM DM.
• A regra RPF funciona.
• A seleção DR é semelhante.
• O mecanismo das mensagens Prune Overrides e Assert é semelhante.

Para controlar quem, onde e que tipo de tráfego multicast é necessário na rede, é necessário um centro de informações comum. Nosso centro será o Ponto de Encontro (RP). Quem quer algum tipo de tráfego multicast ou alguém começou a receber tráfego multicast da origem, então ele envia para o RP.
Quando o RP receber tráfego multicast, ele o enviará para os roteadores que solicitaram anteriormente esse tráfego.

Vamos imaginar uma topologia onde RP é R3. Assim que R1 recebe tráfego de S1, ele encapsula esse pacote multicast em uma mensagem unicast PIM Register e a envia para RP. Como ele sabe quem é o RP? Neste caso, ele é configurado estaticamente e falaremos sobre a configuração dinâmica do RP posteriormente.

endereço ip pim rp 3.3.3.3

O RP vai procurar - houve informação de alguém que gostaria de receber esse tráfego? Vamos supor que não foi. Então o RP enviará a R1 uma mensagem PIM Register-Stop, o que significa que ninguém precisa desse multicast, o registro foi negado. R1 não enviará multicast. Mas o host de origem multicast irá enviá-lo, de modo que R1, após receber Register-Stop, iniciará um temporizador de supressão de registro igual a 60 segundos. 5 segundos antes deste temporizador expirar, R1 enviará uma mensagem de registro vazia com um bit de registro nulo (ou seja, sem um pacote multicast encapsulado) para RP. O RP, por sua vez, atuará assim:

• Se não houver destinatários, ele responderá com uma mensagem Register-Stop.
• Se os destinatários aparecerem, ele não responderá de forma alguma. R1, não tendo recebido uma recusa de registro em 5 segundos, ficará satisfeito e enviará uma mensagem de registro com multicast encapsulado para RP.

Parece que descobrimos como o multicast atinge o RP, agora vamos tentar responder à questão de como o RP entrega o tráfego aos destinatários. Aqui é necessário introduzir um novo conceito - árvore de caminho raiz (RPT). RPT é uma árvore enraizada em RP, crescendo em direção aos destinatários, ramificando-se em cada roteador PIM-SM. O RP o cria recebendo mensagens PIM Join e adiciona uma nova ramificação à árvore. E assim, todo roteador downstream faz. A regra geral é assim:

• Quando um roteador PIM-SM recebe uma mensagem PIM Join em qualquer interface diferente da interface atrás da qual o RP está oculto, ele adiciona uma nova ramificação à árvore.
• Uma ramificação também é adicionada quando o roteador PIM-SM recebe um relatório de associação IGMP de um host conectado diretamente.

Vamos imaginar que temos um cliente multicast no roteador R5 para o grupo 228.8.8.8. Assim que R5 recebe o Relatório de Associação IGMP do host, R5 envia um PIM Join na direção do RP e adiciona uma interface à árvore que olha para o host. Em seguida, R4 recebe PIM Join de R5, adiciona a interface Gi0/1 à árvore e envia PIM Join na direção de RP. Finalmente, RP (R3) recebe PIM Join e adiciona Gi0/0 à árvore. Assim, o destinatário multicast é registrado. Estamos construindo uma árvore com a raiz R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Depois disso, um PIM Join será enviado para R1 e R1 começará a enviar tráfego multicast. É importante observar que se o host solicitou tráfego antes do início da transmissão multicast, o RP não enviará PIM Join e não enviará nada para R1.
Se de repente, enquanto um multicast está sendo enviado, o host parar de querer recebê-lo, assim que o RP receber um PIM Prune na interface Gi0/0, ele enviará imediatamente um PIM Register-Stop diretamente para R1, e então um PIM Prune mensagem através da interface Gi0/1. O PIM Register-stop é enviado via unicast para o endereço de onde veio o PIM Register.
Como dissemos anteriormente, assim que um roteador envia um PIM Join para outro, por exemplo R5 para R4, então um registro é adicionado a R4:

E é iniciado um cronômetro que R5 deve zerar constantemente esse cronômetro PIM Join mensagens constantemente, caso contrário R4 será excluído da lista de saída. R5 enviará a cada 60 mensagens PIM Join.
Troca de árvore de caminho mais curto.
Adicionaremos uma interface entre R1 e R5 e veremos como o tráfego flui com esta topologia.

Suponhamos que o tráfego foi enviado e recebido de acordo com o antigo esquema R1-R2-R3-R4-R5, e aqui conectamos e configuramos a interface entre R1 e R5.
Primeiro de tudo, temos que reconstruir a tabela de roteamento unicast em R5 e agora a rede 192.168.1.0/24 é alcançada através da interface R5 Gi0/2. Agora R5, recebendo multicast na interface Gi0/1, entende que a regra RPF não está satisfeita e seria mais lógico receber multicast na interface Gi0/2. Ele deve se desconectar do RPT e construir uma árvore mais curta chamada Shortest-Path Tree (SPT). Para fazer isso, ele envia PIM Join para R0 através de Gi2/1 e R1 começa a enviar um multicast também através de Gi0/2. Agora o R5 precisa cancelar a assinatura do RPT para não receber duas cópias. Para isso, ele envia ao Prune uma mensagem indicando o endereço IP de origem e inserindo um bit especial - RPT-bit. Isso significa que você não precisa me enviar tráfego, tenho uma árvore melhor aqui. O RP também envia mensagens PIM Prune para R1, mas não envia uma mensagem Register-Stop. Outro recurso: R5 agora enviará continuamente PIM Prune para RP, enquanto R1 continua enviando PIM Register para RP a cada minuto. Até que não haja novas pessoas querendo esse tráfego, o RP irá recusá-lo. R5 notifica RP que continua recebendo multicast via SPT.
Pesquisa dinâmica de RP.
RP automático.
Esta tecnologia é propriedade da Cisco e não é particularmente popular, mas ainda está viva. A operação do Auto-RP consiste em duas etapas principais:
1) O RP envia mensagens RP-Announce para o endereço reservado - 224.0.1.39, declarando-se RP para todos ou para grupos específicos. Esta mensagem é enviada a cada minuto.
2) É necessário um agente de mapeamento RP, que enviará mensagens RP-Discovery indicando para quais grupos qual RP deve ser escutado. É a partir desta mensagem que os roteadores PIM regulares determinarão o RP por si próprios. O Agente de Mapeamento pode ser o próprio roteador RP ou um roteador PIM separado. O RP-Discovery é enviado para o endereço 224.0.1.40 com um temporizador de um minuto.
Vejamos o processo com mais detalhes:
Vamos configurar R3 como RP:

ip pim send-rp-announce loopback 0 escopo 10

R2 como agente de mapeamento:

ip pim send-rp-discovery loopback 0 escopo 10

E em todos os outros esperaremos RP via Auto-RP:

ouvinte de autorp ip pim

Assim que configurarmos o R3, ele começará a enviar RP-Announce:

E o R2, após configurar o agente de mapeamento, começará a aguardar a mensagem RP-Announce. Somente quando encontrar pelo menos um RP ele começará a enviar RP-Discovery:

Dessa forma, assim que os roteadores regulares (PIM RP Listener) receberem esta mensagem, eles saberão onde procurar o RP.
Um dos principais problemas do Auto-RP é que para receber mensagens RP-Announce e RP-Discovery é necessário enviar PIM Join para os endereços 224.0.1.39-40, e para enviar é necessário saber para onde está o RP está localizado. Problema clássico do ovo e da galinha. Para resolver este problema, o PIM Sparse-Dense-Mode foi inventado. Se o roteador não conhece RP, ele opera no modo Denso; se conhece, então no modo Esparso. Quando o modo PIM Sparse e o comando ip pim autorp listener são configurados nas interfaces de roteadores regulares, o roteador operará no modo Denso apenas para multicasting diretamente do protocolo Auto-RP (224.0.1.39-40).
Roteador BootStrap (BSR).
Esta função funciona de forma semelhante ao Auto-RP. Cada RP envia uma mensagem ao agente de mapeamento, que coleta informações de mapeamento e depois informa todos os outros roteadores. Vamos descrever o processo de forma semelhante ao Auto-RP:
1) Depois de configurarmos R3 como candidato a RP, com o comando:

ip pim rp-candidato loopback 0

Então R3 não fará nada; para começar a enviar mensagens especiais, ele primeiro precisa encontrar um agente de mapeamento. Assim, passamos para a segunda etapa.
2) Configure R2 como agente de mapeamento:

ip pim bsr-candidato loopback 0

R2 passa a enviar mensagens PIM Bootstrap, onde se indica como agente de mapeamento:

Esta mensagem é enviada para o endereço 224.0.013, que o protocolo PIM também utiliza para suas demais mensagens. Ele os envia em todas as direções e, portanto, não há problema do ovo e da galinha como havia no Auto-RP.
3) Assim que o RP receber uma mensagem do roteador BSR, ele enviará imediatamente uma mensagem unicast para o endereço do roteador BSR:

Após isso, o BSR, tendo recebido informações sobre os RPs, irá enviá-los por multicast para o endereço 224.0.0.13, que é escutado por todos os roteadores PIM. Portanto, um análogo do comando ouvinte de autorp ip pim para roteadores regulares que não estão em BSR.
Anycast RP com protocolo de descoberta de origem multicast (MSDP).
Auto-RP e BSR nos permitem distribuir a carga no RP da seguinte forma: Cada grupo multicast possui apenas um RP ativo. Não será possível distribuir a carga de um grupo multicast em vários RPs. O MSDP faz isso emitindo aos roteadores RP o mesmo endereço IP com uma máscara de 255.255.255.255. O MSDP aprende informações usando um dos métodos: estático, Auto-RP ou BSR.

Na foto temos uma configuração Auto-RP com MSDP. Ambos os RPs são configurados com endereço IP 172.16.1.1/32 na interface Loopback 1 e são usados ​​para todos os grupos. Com o RP-Announce, ambos os roteadores se anunciam referindo-se a este endereço. O agente de mapeamento Auto-RP, tendo recebido as informações, envia RP-Discovery sobre o RP com o endereço 172.16.1.1/32. Informamos aos roteadores sobre a rede 172.16.1.1/32 usando IGP e, consequentemente. Assim, os roteadores PIM solicitam ou registram fluxos do RP especificado como o próximo salto na rota para a rede 172.16.1.1/32. O próprio protocolo MSDP foi projetado para que os próprios RPs troquem mensagens sobre informações multicast.
Considere esta topologia:

Switch6 transmite tráfego para o endereço 238.38.38.38 e até agora apenas RP-R1 sabe disso. Switch7 e Switch8 solicitaram este grupo. Os roteadores R5 e R4 enviarão PIM Join para R1 e R3, respectivamente. Por que? A rota para 13.13.13.13 para R5 se referirá a R1 usando a métrica IGP, assim como para R4.
RP-R1 sabe do stream e começará a transmiti-lo para R5, mas R4 não sabe nada sobre ele, pois R1 não irá simplesmente enviá-lo. Portanto, o MSDP é necessário. Nós configuramos em R1 e R5:

ip msdp peer 3.3.3.3 conectar-fonte Loopback1 em R1

ip msdp peer 1.1.1.1 conectar-fonte Loopback3 em R3

Eles irão iniciar uma sessão entre si e ao receber algum fluxo irão reportá-lo ao seu vizinho RP.
Assim que o RP-R1 receber um stream do Switch6, ele enviará imediatamente uma mensagem unicast MSDP Source-Active, que conterá informações como (S, G) - informações sobre a origem e o destino do multicast. Agora que o RP-R3 sabe que uma fonte como o Switch6, ao receber uma solicitação do R4 para este fluxo, enviará PIM Join para o Switch6, guiado pela tabela de roteamento. Conseqüentemente, R1 tendo recebido tal PIM Join começará a enviar tráfego para RP-R3.
O MSDP é executado em TCP, os RPs enviam mensagens de manutenção de atividade uns aos outros para verificar a atividade. O cronômetro é de 60 segundos.
A função de dividir os pares MSDP em diferentes domínios permanece obscura, uma vez que as mensagens Keepalive e SA não indicam associação a nenhum domínio. Além disso, nesta topologia testamos uma configuração indicando diferentes domínios - não houve diferença de desempenho.
Se alguém puder esclarecer, ficarei feliz em ler nos comentários.

Fonte: habr.com