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.
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
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.
Ok, That's all about Protocolo PIM-SM no Roteamento Multicast Thank you for visiting, and have a nice day
Protocolo PIM-SM no Roteamento Multicast
0 komentar:
Post a Comment