domingo, 13 de janeiro de 2013

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.

2 comentários:

  1. Caro;

    Estou tentando testar essa configuração entre 2 switch cisco layer 3 que tem 1 port-channel entre eles e somente o igmp snooping querier nos switch. O problema é que qualquer tráfego multicast que gero em um switch aparece no outro sem solicitar. O objetico é elimiar esse problema ativando roteamento multicast.

    Fiz as configurações como R1 e R2 do exemplo mais não esta passando o tráfego multicast. Poderia me dar uma ajuda do que pode estar errado?

    Obrigado, Flávio.

    ResponderExcluir
  2. Your post is comprehensive and thorough love to read more from you.
    In today’s job market, Salesforce skills are highly recommended. Community Cloud Consultant serves as a foundational benchmark for real world Salesforce skills across the container industry. Are you ready to prove your Salesforce skills? Get Salesforce Certified today! Salesforce Certifications are designed to reflect the needs of organizations and IT Professionals

    If you want to pass Salesforce exam in first attempt
    You can get Salesforce Community Cloud Consultant.

    ResponderExcluir