O Protocolo PIM é um conjunto de protocolos para a transmissão de multicast em redes entre roteadores. As relações de vizinhança são estabelecidas de forma semelhante à 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 (Todos os Roteadores PIM). A mensagem contém Hold Timers — geralmente igual a 3,5 vezes o Hello Timer, ou seja, 105 segundos por padrão.
O PIM utiliza dois modos principais de operação — Modo Denso e Modo Ralo. Comecemos pelo Modo Denso.
Árvores de Distribuição Baseadas em Fonte.
O modo Denso é adequado para situações com um grande número de clientes em diversos grupos multicast. Quando um roteador recebe tráfego multicast, ele primeiro verifica a regra RPF. A RPF é uma regra usada para verificar a origem do multicast com a tabela de roteamento unicast. É necessário que o tráfego chegue à interface correspondente ao host de acordo com a tabela de roteamento unicast. Este mecanismo resolve o problema de loops durante a transmissão de multicast.
O R3, a partir da mensagem multicast, descobre a origem do multicast (Source IP) e verifica dois fluxos provenientes de R1 e R2 na sua tabela unicast. O fluxo da interface indicada pela tabela (R1 para R3) será transmitido, enquanto o fluxo de R2 será descartado, pois para chegar à origem do multicast, é necessário enviar pacotes pela S0/1.
A pergunta é o que acontece se você tiver duas rotas equivalentes com a mesma métrica? Nesse caso, o roteador escolherá com base no next-hop dessas rotas. Aquele com o IP mais alto é o ganhador. Se for necessário alterar esse comportamento, pode-se usar ECMP. Mais detalhes .
Após verificar a regra RPF, o roteador envia o pacote multicast a todos os seus vizinhos PIM, exceto àquele de onde o pacote foi recebido. Os demais roteadores PIM repetem esse processo. O caminho que o pacote multicast percorre da fonte até os destinatários finais forma uma árvore, chamada de árvore de distribuição baseada em fonte, árvore de caminho mais curto (SPT), árvore de origem. Três nomes diferentes, escolha qualquer um.
Como resolver a questão de que alguns roteadores não desejam um determinado fluxo multicast e para os quais não há destinatário, mas o roteador ascendente ainda o envia. Para isso, foi desenvolvido o mecanismo Prune.
Mensagem Prune.
Por exemplo, o R2 continuará enviando multicast para o R3, embora o R3, seguindo a regra RPF, o descarte. Para que sobrecarregar o canal? O R3 envia uma Mensagem PIM Prune e o R2, ao receber esta mensagem, removerá a interface S0/1 da lista (outgoing interface list) para este fluxo, a lista de interfaces das quais deve enviar este tráfego.
A seguir, uma definição mais formal de uma mensagem PIM Prune:
A mensagem PIM Prune é enviada por um roteador a um segundo roteador para fazer com que o segundo roteador remova o link onde o Prune é recebido de uma SPT (S,G) específica.
Após receber a mensagem Prune, o R2 configura o timer de Prune para 3 minutos. Após três minutos, ele começará a enviar tráfego novamente, até receber outra mensagem Prune. Isso ocorre no PIMv1.
No PIMv2, foi adicionado um timer de State Refresh (por padrão 60 segundos). Assim que uma mensagem Prune é enviada pelo R3, esse timer é acionado no R3. Ao final deste timer, o R3 enviará uma mensagem de State Refresh, que irá redefinir o timer de Prune de 3 minutos no R2 para este grupo.
Razões para enviar a mensagem Prune:
- Quando um pacote multicast não passou na verificação RPF.
- Quando não há clientes conectados localmente que solicitaram o grupo multicast (IGMP Join) e não há vizinhos PIM para quem enviar o tráfego multicast (Non-prune Interface).
Mensagem Graft.
Vamos imaginar que o R3 não quis tráfego do R2, enviou Prune e recebeu multicast do R1. Mas, de repente, a conexão entre R1-R3 falhou e o R3 ficou sem multicast. Podemos esperar 3 minutos até que o Timer de Prune no R2 expire. Esperar 3 minutos é muito tempo; para não esperar, é necessário enviar uma mensagem que imediatamente retire a interface S0/1 no R2 do estado podado. Esta mensagem será a mensagem Graft. Após receber a mensagem Graft, o R2 enviará em resposta um Graft-ACK.
Prune Override.
Vamos analisar este esquema. R1 transmite multicast para o segmento com dois roteadores. R3 recebe e transmite o tráfego, R2 recebe, mas não há ninguém para transmitir o tráfego. Ele envia uma mensagem Prune para R1 neste segmento. R1 deve remover Fa0/0 da lista e parar de transmitir para este segmento, mas o que acontecerá com R3? R3 está no mesmo segmento, também recebeu essa mensagem Prune e entendeu a tragédia da situação. Antes que R1 pare de transmitir, ele configura um timer de 3 segundos e vai parar de transmitir em 3 segundos. São exatamente 3 segundos que R3 tem para não perder seu multicast. Portanto, R3, o mais rápido possível, envia uma mensagem Pim Join para este grupo e R1 já não pensa mais em parar de transmitir. Sobre as mensagens Join abaixo.
Mensagem Assert.
Imaginemos a seguinte situação: dois roteadores transmitem simultaneamente em uma rede. Ambos recebem o mesmo fluxo de uma fonte e ambos o transmitem em uma rede através da interface e0. Portanto, eles precisam determinar quem será o único transmissor para esta rede. Para isso, são utilizadas mensagens Assert. Quando R2 e R3 detectam a duplicação do tráfego multicast, ou seja, quando R2 e R3 recebem o multicast que eles mesmos estão transmitindo, os roteadores entendem que algo não está certo. Nesse caso, eles enviam mensagens Assert, que incluem a Distância Administrativa e a métrica da rota através da qual a fonte multicast é alcançada — 10.1.1.10. O vencedor é determinado assim:
- Aquele com a AD mais baixa.
- Se a AD for igual, verifica-se quem tem a métrica mais baixa.
- Se ainda estiver igual, é aquele que tiver o IP mais alto na rede para a qual eles transmitem este multicast.
O vencedor nesta votação, o roteador se torna o Roteador Designado. Para escolher o DR, também são utilizados os Pim Hello. No início do artigo, foi exibida uma mensagem PIM Hello, onde pode-se notar o campo DR. Vence aquele que tiver o endereço IP mais alto nesta conexão.
Tabela útil:
Tabela MROUTE.
Após a consideração inicial do funcionamento do protocolo PIM, precisamos entender como trabalhar com a tabela de roteamento multicast. A tabela mroute armazena informações sobre quais fluxos foram solicitados pelos clientes e quais fluxos estão sendo transmitidos pelos servidores multicast.
Por exemplo, ao receber um IGMP Membership Report ou PIM Join em alguma interface, uma entrada do tipo (*, G) é adicionada à tabela de roteamento:
Esta entrada indica que uma solicitação de tráfego foi recebida do endereço 238.38.38.38. A flag DC significa que o multicast funcionará em modo Dense e C indica que o receptor está diretamente conectado ao roteador, ou seja, o roteador recebeu um IGMP Membership Report e um PIM Join.
Se houver uma entrada do tipo (S,G), isso significa que temos um fluxo multicast:
No campo S — 192.168.1.11, temos o endereço IP da fonte do multicast, que será verificado pela regra RPF. Em caso de problemas, devemos primeiro verificar a tabela unicast para o caminho até a fonte. O campo Incoming Interface indica a interface pela qual o multicast chega. Na tabela de roteamento unicast, o caminho até a fonte deve referenciar a interface indicada aqui. No campo Outgoing Interface, é indicado para onde o multicast será redirecionado. Se estiver vazio, significa que o roteador não recebeu solicitações para esse tráfego. Informações mais detalhadas sobre todas as flags podem ser encontradas. .
PIM Sparse-mode.
A estratégia Sparse-mode é oposta à Dense-mode. Quando o Sparse-mode recebe tráfego multicast, ele só enviará o tráfego através das interfaces onde houve solicitações para esse fluxo, como mensagens Pim Join ou IGMP Report solicitando esse tráfego.
Elementos semelhantes entre SM e DM:
- As relações de vizinhança são estabelecidas da mesma forma que no PIM DM.
- A regra RPF funciona.
- A escolha do DR é semelhante.
- O mecanismo Prune Overrides e as mensagens Assert são análogas.
Para controlar quem, onde e que tráfego multicast é necessário na rede, é necessário um centro de informações comum. Esse centro será o Rendezvous Point (RP). Todos que desejam algum tráfego multicast ou que começaram a receber tráfego multicast de uma fonte enviam suas solicitações ao 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 o RP é R3. Assim que R1 receber tráfego de S1, ele encapsulará este pacote multicast em uma mensagem unicast PIM Register e enviará para o RP. Como ele sabe quem é o RP? Nesse caso, ele está configurado estaticamente, e falaremos sobre a configuração dinâmica do RP mais tarde.
ip pim rp-address 3.3.3.3
O RP verificará se houve informações de alguém que desejasse receber esse tráfego? Suponhamos que não. Então, o RP enviará uma mensagem PIM Register-Stop para o R1, o que significa que ninguém precisa desse multicast, a inscrição foi negada. O R1 não enviará o multicast. Mas a fonte do multicast enviará, então, após receber o Register-Stop, o R1 iniciará um temporizador Register-Suppression de 60 segundos. Quinze segundos antes do final desse temporizador, o R1 enviará uma mensagem Register em branco com o bit Null-Register (ou seja, sem pacote multicast encapsulado) em direção ao RP. O RP, por sua vez, agirá da seguinte forma:
- Se não houve destinatários, ele responderá com uma mensagem Register-Stop.
- Se surgirem destinatários, ele não responderá a ela. O R1, não recebendo uma negativa à sua inscrição dentro de 5 segundos, ficará feliz e enviará uma mensagem Register com multicast encapsulado para o RP.
Como o multicast chega ao RP parece estar claro, agora tentaremos responder à pergunta de como o RP leva o tráfego até os destinatários. Aqui precisamos introduzir um novo conceito — a árvore de caminho raiz (root-path tree, RPT). A RPT é uma árvore com raiz no RP, crescendo em direção aos destinatários, ramificando-se em cada roteador PIM-SM. O RP a cria ao receber mensagens PIM Join e adiciona um novo ramo à árvore. E assim, faz cada roteador inferior. A regra geral é a seguinte:
- Quando um roteador PIM-SM recebe uma mensagem PIM Join em alguma interface, exceto na interface onde está o RP, ele adiciona um novo ramo à árvore.
- Um ramo também é adicionado quando um roteador PIM-SM recebe um IGMP Membership Report de um host diretamente conectado.
Suponhamos que temos um cliente multicast no roteador R5 para o grupo 228.8.8.8. Assim que o R5 receber o IGMP Membership Report do host, o R5 enviará um PIM Join em direção ao RP e adicionará à árvore a interface voltada para o host. Então, o R4 receberá o PIM Join do R5, adicionará a interface Gi0/1 à árvore e enviará o PIM Join em direção ao RP. Por fim, o RP (R3) receberá o PIM Join e adicionará Gi0/0 à árvore. Assim, a inscrição do destinatário multicast é realizada. Formamos uma árvore com a raiz R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Após isso, um PIM Join será enviado ao R1 e o R1 começará a enviar tráfego multicast. É importante notar que, se o host solicitar tráfego antes do início da transmissão multicast, o RP não enviará o PIM Join e, de fato, não enviará nada para o R1.
Se, durante o envio do multicast, o host parar de querer recebê-lo, assim que o RP receber um PIM Prune na interface Gi0/0, ele imediatamente enviará um PIM Register-Stop diretamente para o R1 e, em seguida, a mensagem PIM Prune através da interface Gi0/1. O PIM Register-stop é enviado via unicast para o endereço de onde o PIM Register foi recebido.
Como mencionamos anteriormente, assim que o roteador envia um PIM Join para outro, por exemplo, R5 para R4, uma entrada será adicionada no R4:
E um temporizador é iniciado, que deve ser constantemente resetado pelo R5 através do envio de mensagens PIM Join; caso contrário, o R4 o excluirá da lista de saída. O R5 enviará mensagens PIM Join a cada 60 segundos.
Mudança do Shortest-Path Tree.
Adicionaremos uma interface entre o R1 e o R5 e veremos como o tráfego fluirá com essa topologia.
Suponha que o tráfego foi enviado e recebido pelo antigo esquema R1-R2-R3-R4-R5, e agora conectamos e configuramos a interface entre o R1 e o R5.
Primeiro, a tabela de roteamento unicast no R5 será reorganizada, e agora a rede 192.168.1.0/24 será alcançada através da interface R5 Gi0/2. Agora, ao receber multicast na interface Gi0/1, o R5 entende que a regra RPF não está sendo satisfeita e que seria mais lógico receber o multicast na Gi0/2. Ele deve se desconectar do RPT e construir uma árvore mais curta, chamada Shortest-Path Tree (SPT). Para isso, ele envia um PIM Join ao R1 pela Gi0/2 e o R1 começa a enviar multicast também pela Gi0/2. Agora, o R5 precisa cancelar sua subscrição do RPT, para não receber duas cópias. Para isso, ele envia uma mensagem Prune, indicando o endereço IP da fonte e inserindo um bit especial — RPT-bit. Isso significa que não é necessário me enviar tráfego, pois eu aqui tenho uma árvore melhor. O RP também envia mensagens PIM Prune em direção ao R1, mas não envia a mensagem Register-Stop. Outra característica: o R5 agora enviará continuamente PIM Prune para o RP, já que o R1 continua enviando PIM Register para o RP a cada minuto. O RP, enquanto não houver novos interessados nesse tráfego, responderá com uma recusa. O R5 informa ao RP que continua recebendo multicast através do SPT.
Busca dinâmica de RP.
Auto-RP.
Esta tecnologia é proprietária da Cisco e não é muito popular, mas ainda está em uso. 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, seja para todos ou para grupos específicos. Esta mensagem é enviada a cada minuto.
2) Um agente de mapeamento RP é necessário, que irá enviar mensagens RP-Discovery indicando para quais grupos determinado RP deve ser ouvido. É a partir desta mensagem que os roteadores PIM comuns irão determinar seu RP. O Mapping Agent pode ser tanto o próprio roteador RP quanto um roteador PIM separado. O RP-Discovery é enviado para o endereço 224.0.1.40 com um timer de um minuto.
Vamos analisar o processo com mais detalhes:
Vamos configurar o R3 como RP:
ip pim send-rp-announce loopback 0 scope 10
R2 como agente de mapeamento:
ip pim send-rp-discovery loopback 0 scope 10
E em todos os outros, vamos aguardar o RP através do Auto-RP:
ip pim autorp listener
Assim que configurarmos o R3, ele começará a enviar RP-Announce:
E o R2, após a configuração como agente de mapeamento, começará a aguardar as mensagens RP-Announce. Somente quando encontrar pelo menos um RP, começará a enviar RP-Discovery:
Dessa forma, assim que os roteadores comuns (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 um PIM Join para os endereços 224.0.1.39-40, mas, para enviar, é preciso saber onde está o RP. É o clássico problema do ovo e da galinha. Para resolver esse problema, foi inventado o modo PIM Sparse-Dense-Mode. Se o roteador não conhece o RP, ele opera no modo Dense-mode; se conhece, no modo Sparse-mode. Quando as interfaces dos roteadores normais estão configuradas para PIM Sparse-mode e o comando ip pim autorp listener, o roteador operará no modo Dense-mode apenas para o multicast diretamente do protocolo Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Esta função opera de forma semelhante ao Auto-RP. Cada RP envia uma mensagem para o agente de mapeamento, que coleta informações de mapeamento e, em seguida, informa todos os outros roteadores. Vamos descrever o processo de maneira análoga ao Auto-RP:
1) Assim que configurarmos o R3 como candidato para ser RP, com o comando:
ip pim rp-candidate loopback 0
O R3 não fará nada, para começar a enviar mensagens especiais, ele precisa primeiro encontrar o agente de mapeamento. Então, passamos para o segundo passo.
2) Configuramos o R2 como agente de mapeamento:
ip pim bsr-candidate loopback 0
O R2 começa a enviar mensagens PIM Bootstrap, se apresentando como agente de mapeamento:
Essa mensagem é enviada para o endereço 224.0.0.13, que o protocolo PIM usa também para outras de suas mensagens. Ele as envia em todas as direções, portanto não há o problema da galinha e do ovo, como no Auto-RP.
3) Assim que o RP receber uma mensagem do roteador BSR, ele imediatamente enviará uma mensagem unicast para o endereço do roteador BSR:
Em seguida, o BSR, ao receber as informações sobre o RP, as disseminará via multicast para o endereço 224.0.0.13, que é monitorado por todos os roteadores PIM. Portanto, não existe um comando equivalente ip pim autorp listener para roteadores comuns no BSR.
Anycast RP com o Protocolo de Descoberta de Fonte Multicast (MSDP).
Auto-RP e BSR nos permitem distribuir a carga no RP da seguinte forma: cada grupo multicast tem apenas um RP ativo. Não é possível distribuir a carga para um único grupo multicast com vários RPs. O MSDP faz isso fornecendo aos roteadores RP o mesmo endereço IP com uma máscara de 255.255.255.255. O MSDP obtém informações através de um dos métodos: estático, Auto-RP ou BSR.
Na imagem temos a configuração do Auto-RP com MSDP. Ambos os RPs estão configurados com o endereço IP 172.16.1.1/32 na interface Loopback 1 e é usado para todos os grupos. Durante o RP-Announce, ambos os roteadores informam sobre si mesmos, referindo-se a esse endereço. O agente de mapeamento Auto-RP, ao receber as informações, dissemina a descoberta do RP com o endereço 172.16.1.1/32. Sobre a rede 172.16.1.1/32, informamos aos roteadores por meio do IGP e, consequentemente. Assim, os roteadores PIM solicitam ou registram fluxos com o RP que está indicado como próximo salto na rota para a rede 172.16.1.1/32. O próprio protocolo MSDP é destinado especificamente para os RPs, para trocar mensagens sobre informações de multicast.
Vamos considerar a seguinte topologia:
O Switch6 transmite tráfego para o endereço 238.38.38.38, do qual apenas o RP-R1 está ciente. O Switch7 e o Switch8 solicitaram este grupo. Os roteadores R5 e R4 enviarão PIM Join para R1 e R3, respectivamente. Por quê? A rota até 13.13.13.13 no R5 irá referir-se ao R1 pela métrica do IGP, assim como no R4.
O RP-R1 está ciente do fluxo e começará a transmiti-lo em direção ao R5, enquanto o R4 não possui conhecimento sobre ele, pois o R1 não o enviará apenas assim. Portanto, o MSDP se faz necessário. Vamos configurá-lo no R1 e R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 no R1
ip msdp peer 1.1.1.1 connect-source Loopback3 no R3
Eles estabelecerão uma sessão entre si e, ao receber qualquer fluxo, informarão ao seu RP vizinho.
O RP-R1, assim que receber o fluxo do Switch6, enviará imediatamente uma mensagem MSDP Source-Active via unicasts, contendo informações do tipo (S, G) — informações sobre a origem e o destino do multicast. Agora, quando o RP-R3 souber que há uma origem como o Switch6, ao receber uma solicitação do R4 para esse fluxo, enviará um PIM Join em direção ao Switch6, com base na tabela de roteamento. Portanto, o R1, ao receber tal PIM Join, começará a enviar tráfego em direção ao RP-R3.
O MSDP opera sobre TCP, e os RPs trocam mensagens de keepalive para verificar a viabilidade. O timer é de 60 segundos.
A função de segmentação dos pares do MSDP em diferentes domínios permanece obscura, pois as mensagens Keepalive e SA não indicam a que domínio pertencem. Além disso, nesta topologia, foi testada uma configuração com a indicação de diferentes domínios — não houve diferença no funcionamento.
Se alguém puder esclarecer, ficarei feliz em ler nos comentários.
Fonte: habr.com
