Protocolo PIM-DM no Roteamento Multicast

Olá Pessoal.

Uma dúvida comum que vejo quando os alunos estão aprendendo os fundamentos do endereço IPv4 diz respeito à Classe D (de 224.0.0.0 até 239.255.255.255), reservada para fins de comunicação multicast.

O tipo mais comum de comunicação no contexto de uma rede de computadores é aquela de uma máquina (origem) para outra máquina (destino), ou seja, uma comunicação de um-para-um que chamamos de unicast.

No entanto, essa não é a única forma de comunicação possível. Existem outras abordagens, como por exemplo a comunicação multicast (um-para-muitos), anycast (um-para-algum, normalmente o mais próximo) e o broadcast (um-para-todos). 

A proposta de escrever um livro de natureza hands-on (mão na massa) veio do meu entendimento de que a prática é uma excelente ferramenta de apoio na compreensão da teoria. Por isso o objetivo desse post é tentar solidificar o conceito de multicast através de um pouco de configuração. ;-)

Também é muito comum quando se estuda roteamento que o foco esteja voltado para os tradicionais protocolos de roteamento unicast como o RIP, OSPF e EIGRP. A essência de todos esses protocolos é que cada um deles possui um algoritmo próprio com lógicas diferentes (uns são distance-vector, outros são link-state), no entanto todos têm o mesmo fim: identificar um caminho (rota) até UM destino. Então fica claro que o roteamento tradicionalmente estudado em sala de aula trata de comunicações unicast.

Esses mesmos protocolos não poderiam ser utilizados para fins de comunicação multicast porque a natureza da comunicação é diferente. Esses protocolos foram desenvolvidos para chegar a um destino, enquanto que o objetivo do multicast é encontrar múltiplos destinos!

Eis então que cabe uma boa pergunta: "Ok, já entendi que a comunicação multicast é aquela originada de uma máquina para muitas, mas em termos práticos qual seria um exemplo de situação em que eu iria querer fazer isso?" O conteúdo que trefega nas redes de computadores nunca esteve tão multimídia como atualmente e o vídeo vem se disseminando cada vez mais. Bons exemplos de aplicações multicast são aquelas que fazem streaming de vídeo, tais como vídeo sob demanda e vídeo-conferência. Outro exemplo menos tradicional seriam aplicações distribuídas para fins de monitoramento dos nós.

Nesse caso a aplicação servidora que gera o conteúdo precisa ser capaz de identificar quais destinos da rede estão interessados em receber esse conteúdo. Fazer isso isoladamente através de múltiplas conexões unicast seria muito ruim em termos de desempenho porque teríamos repetidos pacotes trafegando pela rede. Através da comunicação multicast a aplicação servidora envia todo o tráfego para um único endereço de natureza multicast e cabe à aplicação cliente associar os hosts interessados no conteúdo com o devido grupo multicast, que na prática é identificado através da Classe D. 

Por exemplo, um pacote endereçado para 226.1.1.1 tem como destino um grupo de máquinas que estão associadas com esse endereço. Ou seja, esse endereço pertence REPETIDAMENTE a um grupo de máquinas e cabe às aplicações gerenciar as associações! Ele não é único a um host como os tradicionais endereços unicast. Ahhh, então as coisas estão começando a fazer mais sentido, não é? Que bom!!! 

Dos protocolos de roteamento multicast existentes, os dois mais tradicionais no mercado são o PIM-DM (Protocol Independent Multicast - Dense Mode) e o PIM-SM (Protocol Independent Multicast - Sparse Mode). Eles são chamados de "independentes de protocolo" porque utilizam a lógica dos protocolos de roteamento unicast como apoio para evitar a ocorrência de loop na rede, como será explicado mais adiante. 

No cenário abaixo existe um servidor que "gera" um fluxo multicast para o grupo 226.1.1.1 e temos um único host cliente que estaremos associando com esse grupo para receber o conteúdo. O processo de configurar um ou "n" hosts é o mesmo, portanto fique à vontade para ampliar o cenário! Estarei partindo do princípio de que todos os endereços das interfaces já estão configurados seguindo o plano apresentado e de que já existe um protocolo de roteamento unicast em execução!

 

Como não estou realmente executando uma aplicação multicast no laboratório, então estarei utilizando o "SLA Monitor" para gerar um fluxo de dados qualquer apenas para verificarmos as tabelas multicast. Tenha em mente que na realidade o "SLA Monitor" é uma ferramenta para medir o desempenho da rede! Da mesma forma, como não estou executando uma aplicação cliente no host, então farei a inserção manual dele no grupo via linha de comando.

Então vamos começar pela configuração do Servidor e do Cliente que, na realidade, são roteadores disfarçados de computadores. Tenha em mente que essa etapa é necessária apenas para viabilizar o laboratório e não faz parte da configuração do roteamento multicast na rede! 

Src(config)# ip sla monitor 1
Src(config-sla-monitor)# type echo protocol ipIcmpEcho 226.1.1.1 source-ipaddr 192.168.1.1
Src(config-sla-monitor-echo)# exit
Src(config-sla-monitor)# ip sla monitor schedule 1 start-time now

***

Client(config)# int f0/0
Client(config-if)# ip address 192.168.3.200 255.255.255.0
Client(config-if)# ip igmp join-group 226.1.1.1
  
Feito isso, então vamos para a configuração do roteamento multicast propriamente dito. Nos roteadores estaremos ativando o protocolo PIM-DM e depois das linhas de configuração falarei um pouco da visualização das tabelas de roteamento multicast.

01. R1(config)# ip multicast-routing
02. R1(config)# int f0/0
03. R1(config-if)# ip address 192.168.1.254 255.255.255.0
04. R1(config-if)# ip pim dense-mode
05. R1(config-if)# int s1/0
06. R1(config-if)# clock rate 64000
07. R1(config-if)# ip address 10.95.0.1 255.255.255.252
08. R1(config-if)# ip pim dense-mode
09. R1(config-if)# int s1/1
10. R1(config-if)# clock rate 64000
11. R1(config-if)# ip address 10.96.0.1 255.255.252
12. R1(config-if)# ip pim dense-mode  
13. R1(config-if)# exit
14. R1(config)# router eigrp 90
15. R1(config-router)# network 10.0.0.0
16. R1(config-router)# network 192.168.1.0

A linha 01 é necessária para habilitar o roteamento multicast no roteador, enquanto que as linhas 04, 08 e 12 ativam o protocolo PIM-DM nas interfaces envolvidas no processo. Basicamente, é apenas isso!!! Todas as demais linhas tratam de configurações das interfaces e do protocolo de roteamento unicast que são pré-requisitos para o cenário funcionar adequadamente. O processo de configuração dos roteadores R2 e R3 segue o mesmo racioncínio:

R2(config)# ip multicast-routing
R2(config)# int f0/0
R2(config-if)# ip address 192.168.2.254 255.255.255.0
R2(config-if)# ip pim dense-mode
R2(config-if)# int s1/0
R2(config-if)# ip address 10.95.0.2 255.255.255.252
R2(config-if)# ip pim dense-mode
R2(config-if)# int s1/1
R2(config-if)# clock rate 64000
R2(config-if)# ip address 10.97.0.1 255.255.252
R2(config-if)# ip pim dense-mode  
R2(config-if)# exit
R2(config)# router eigrp 90
R2(config-router)# network 10.0.0.0
R2(config-router)# network 192.168.2.0

***

R3(config)# ip multicast-routing
R3(config)# int f0/0
R3(config-if)# ip address 192.168.3.254 255.255.255.0
R3(config-if)# ip pim dense-mode
R3(config-if)# int s1/0
R3(config-if)# ip address 10.96.0.2 255.255.255.252
R3(config-if)# ip pim dense-mode
R3(config-if)# int s1/1
R3(config-if)# ip address 10.97.0.2 255.255.252
R3(config-if)# ip pim dense-mode  
R3(config-if)# exit
R3(config)# router eigrp 90
R3(config-router)# network 10.0.0.0
R3(config-router)# network 192.168.3.0

Para checar se o cenário está realmente funcionando, vamos olhar para as tabelas de roteamento multicast. Para visualizar a tradicional tabela de rotas unicast utilizamos o comando "show ip route", no caso da tabela multicast o comando é "show ip mroute". O formato dessa tabela é bem diferente, conforme pode ser observado abaixo:

R1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode(...) Saída Omitida

(192.168.1.1, 226.1.1.1), 00:02:33/00:02:34, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/1, Forward/Dense, 00:02:06/00:00:00
    Serial1/0, Prune/Dense, 00:01:34/00:01:25

(...) Saída Omitida

Diferente da tabela de rotas unicast, agora cada entrada na tabela de rotas multicast consiste na tupla (S,G), onde S é a origem e G é o grupo. Nas linhas destacadas a gente observa a entrada (192.168.1.1, 226.1.1.1), indicando que o tráfego multicast é originado pelo servidor 192.168.1.1 e destinado ao grupo 226.1.1.1. A interface f0/0 que está conectada à origem consta como entrada e, diferente da rota unicast, o "destino" é uma relação de interfaces de saída que irão receber o conteúdo. Nesse caso, o conteúdo será encaminhado para as interfaces s1/0 e s1/1 que se conectam aos roteadores R2 e R3. Agora vamos observar e interpretar as tabelas de R2 e R3. 

R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(...) Saída Omitida

(192.168.1.1, 226.1.1.1), 00:01:57/00:01:02, flags: PT
  Incoming interface: Serial1/0, RPF nbr 10.95.0.1
  Outgoing interface list: Null

(...) Saída Omitida
 
***

R3#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(...) Saída Omitida

(192.168.1.1, 226.1.1.1), 00:10:36/00:02:33, flags: T
  Incoming interface: Serial1/0, RPF nbr 10.96.0.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:10:37/00:00:00

(...) Saída Omitida
 

A gente observa que nos roteadores R2 e R3 o tráfego não está sendo encaminhado para todas as interfaces em que ativamos o PIM-DM. Esse comportamento do protocolo impede a ocorrência de loop na rede. 

Vamos tentar enxergar a lógica do protocolo de maneira simplificada: Quando R1 recebe tráfego para 226.1.1.1 é criada uma rota multicast (192.168.1.1, 226.1.1.1) que é propagada para R2 e R3 nas interfaces em que ativamos o PIM-DM. Então R2 reencaminharia essa mesma informação de rota para R1 e R3, mas na realidade ambos os roteadores já têm essa informação. 

Para evitar a ocorrência de loops, o protocolo PIM-DM somente aceita rotas multicast cujo endereço unicast de next-hop seja o mais próximo da origem. E para saber qual vizinho é o mais próximo da origem ele utiliza como apoio as tabelas de roteamento unicast, daí a importância de configurar o roteamento tradicional antes. 

Por exemplo, R2 vai receber a rota (192.168.1.1, 226.1.1.1) via R1 (10.95.0.1) e via R3 (10.97.0.2). Então o PIM-DM consulta a tabela de roteamento unicast para saber qual é o melhor caminho para chegar até a rede da origem (192.168.1.0 /24) e opta pela rota multicast aprendida por R1 (10.95.0.1). É exatamente da mesma forma que R3 opta pela rota por R1 (10.96.0.1).  

Naturalmente existem vários outros conceitos importantes relacionados ao roteamento multicast que vocês leitores devem explorar. O objetivo desse post foi apenas facilitar o entendimento do processo de comunicação multicast que normalmente recebe uma tratativa apenas teórica e isso dificulta o processo de aprendizagem!

Abraço.

Samuel.