Protocolo PIM-SM no Roteamento Multicast

Olá Pessoal.

Em 09/01/2013 escrevi uma postagem intitulada "Protocolo PIM-DM no Roteamento Multicast" que trazia uma breve discussão sobre as principais diferenças entre o roteamento unicast e o roteamento multicast. Naquela oportunidade, para facilitar a explicação, utilizei o cenário abaixo para mostrar ao leitor como configurar o Protocolo PIM-DM.

 

Dessa vez vou utilizar esse mesmo cenário para mostrar como configurar o PIM-SM (Sparse-Mode), um outro protocolo de roteamento multicast que é mais sofisticado do que o PIM-DM (Dense-Mode). No entanto, antes de colocarmos a mão na massa, sempre cabe um pouco de conceito sobre as diferenças entre esses protocolos.

Quando falo que o PIM-SM é mais sofisticado que o PIM-DM é importante que o leitor tenha em mente que em nenhum momento estou dizendo que um é melhor do que o outro... O fato do PIM-SM ser mais complexo que o PIM-DM faz dele mais flexível, no entanto cada um deles tem uma aplicação diferente dependendo do ambiente em que a solução multicast é necessária. Entendê-los conceitualmente é fundamental para saber qual utilizar!

A estratégia de operação do PIM-DM (Dense-Mode) parte do princípio de que "todas" as sub-redes possuem hosts interessados no conteúdo distribuído pela fonte multicast e por isso os roteadores automaticamente propagam os pacotes multicast para TODAS as suas interfaces em que o protocolo foi habilitado, ou seja, é feito o flood (inundação) do conteúdo. 

O PIM-SM (Sparse-Mode) adota uma estratégia oposta porque assume que nenhum host deseja receber o conteúdo multicast até que haja uma manifestação explícita de interesse, o que normalmente é uma vantagem do ponto de vista de desempenho.  Assim surge um novo elemento denominado RP (Rendzvous Point) que é manualmente configurado em todos os roteadores como "ponto de encontro" do tráfego multicast e que fica responsável por receber as manifestações de interesse (join messages) para, então, fazer a distribuição do conteúdo aos demais roteadores.

Isso quer dizer que o RP tem um papel crucial no projeto de um ambiente que utiliza o PIM-SM, uma vez que ele passa a ser SEMPRE o ponto de distribuição do tráfego para os demais interessados. A consequência disso é que o tráfego não ocorre mais no sentido da fonte para o destino, mas sim do RP para o destino (obviamente que é feito o encaminhamento prévio da fonte para o RP). É por causa disso que o posicionamento desse elemento tem que ser cuidadosamente pensado para não subotimizar o desempenho do roteamento.

Como esse post tem a proposta de mostrar o processo de configuração do PIM-SM sem se preocupar com os aspectos de design, estarei utilizando o mesmo cenário e irei atribuir ao R2 a função de RP! Tenha em mente que a topologia apresentada não é a ideal do ponto de vista de desempenho! Nessa postagem não estarei reexplicando como configurar a fonte para gerar conteúdo multicast e o cliente para participar do grupo, já que o leitor pode encontrar essas informações no post de 09/01/2013. 

Vamos focar nas configurações de R1, R2 (o RP) e R3:

01. R1(config)# ip route 1.1.1.1 255.255.255.255 10.95.0.2
02. R1(config)# ip multicast-routing
03. R1(config)# ip pim rp-address 1.1.1.1
04. R1(config)# int f0/0
05. R1(config-if)# ip pim sparse-mode
06. R1(config-if)# int s1/0
07. R1(config-if)# ip pim sparse-mode
08. R1(config-if)# int s1/1
09. R1(config-if)# ip pim sparse-mode

Dessa forma R1 está devidamente configurado. Reparem que na linha 01 criamos uma rota estática apontando para uma interface loopaback de R2 (1.1.1.1), uma boa prática para referenciar o roteador com a função de RP. Uma vez havendo alcançabilidade a essa interface de R2, então na linha 03 é manualmente informado onde o RP pode ser encontrado. Nas linhas 05, 07 e 09 simplesmente estamos habilitando o PIM-SM nas interfaces. Em R2 observem que iremos subir a interface loopback1 (lo1) e atribuir nela o endereço 1.1.1.1/32.

01. R2(config)# int lo 1
02. R2(config-if)# ip address 1.1.1.1 255.255.255.255
03. R2(config-if)# exit
04. R2(config-if)# ip multicast-routing
05. R2(config-if)# ip pim rp-address 1.1.1.1
06. R2(config-if)# int f0/0
07. R2(config-if)# ip pim sparse-mode
08. R2(config-if)# int s1/0
09. R2(config-if)# ip pim sparse-mode
10. R2(config-if)# int s1/1
11. R2(config-if)# ip pim sparse-mode 

Em R2 não foi necessário criar a rota estática porque ao atribuir o endereço 1.1.1.1/32 na interface lo1 já é criada essa entrada na tabela de roteamento como uma rota diretamente conectada. Os demais comandos são iguais, incluvise sendo necessário apontar ele mesmo como RP. Agora vamos para a configuração de R3:
  
01. R3(config)# ip route 1.1.1.1 255.255.255.255 10.97.0.1
02. R3(config)# ip multicast-routing
03. R3(config)# ip pim rp-address 1.1.1.1
04. R3(config)# int f0/0
05. R3(config-if)# ip pim sparse-mode
06. R3(config-if)# int s1/0
07. R3(config-if)# ip pim sparse-mode
08. R3(config-if)# int s1/1
09. R3(config-if)# ip pim sparse-mode

Pronto! A configuração de R3 é praticamente idêntica a de R1, exceto que o next-hop na rota estática para alcançar a interface lo1 de R2 ocorre diretamente através da rota R3>R2, ou seja, via 10.97.0.1. O cenário está devidamente configurado. Para finalizar, vamos observar as tabelas de roteamento multicast de R3:

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

(*, 226.1.1.1), 00:06:13/stopped, RP 1.1.1.1, flags: SJC
  Incoming interface: Serial1/1, RPF nbr 10.97.0.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:06:13/00:02:05
(...) Saída Omitida

Pela tabela a gente observa que a tupla (*, 226.1.1) recebe o conteúdo multicast pela interface s1/1 (conectada a R2 - o RP) e a saída somente é encaminhada pela interface f0/0, já que por ela foi recebida uma manifestação de interesse da máquina cliente conectada na rede local atrás de R3! A principal diferença então é que com o PIM-SM o encaminhamento não é feito para todas as interfaces, mas somente para aquelas realmente interessadas no conteúdo. 

Abraço.

Samuel.

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.