Multicast

Comware7 – Roteamento Multicast: PIM Dense-mode

Diego DiasLeave a comment

A principal função de qualquer protocolo de roteamento dinâmico é auxiliar os roteadores no processo de encaminhamento dos pacotes com a utilização do melhor caminho para um determinado destino. As informações inseridas na tabela de roteamento incluem principalmente: a rede de destino, a forma de aprendizado da rota e o próximo salto, para endereços de rede unicast.

Entretanto quando um roteador recebe um pacote com endereço IPv4 multicast, ele não consegue encaminhar o pacote utilizando a tabela de roteamento IPv4 unicast pois os endereços multicast não são inseridos na tabela.

Os roteadores podem encaminhar os pacotes multicast somente através dos protocolos de roteamento como o multicast dense-mode e sparse-mode, que se utilizam da tabela de roteamento unicast para encaminhamento do trafego.

Nesse artigo abordaremos o processo dense-mode para encaminhamento de tráfego IPv4 multicast Continue reading →

Switches HPN 10500 – Configurando mapeamento estático multicast para NLB em Switches baseados no Comware

Diego Dias7 Comments

O protocolo NLB da Microsot (Network Load Balancing) tem como objetivo o balanceamento de tráfego entre um grupo de Servidores utilizando endereços MAC em multicast. Os clientes que acessam os serviços de um grupo de Servidores com NLB, enxergam o serviço de forma transparente.

Para trabalhar com NLB o Switch deve encaminhar o tráfego com destino ao serviço NLB para todos os servidores especificados no cluster NLB  e cada servidor filtra o tráfego não desejado.

A cooperação entre o Switch e o protocolo NLB é muito importante e dessa forma é importante saber as maneiras que o protcolo NLB trabalha, que são os modos Unicast e Multicast:

Unicast

No modo unicast, NLB substitui o endereço MAC real de cada servidor no cluster para um endereço comum NLB MAC. Quando todos os servidores no cluster têm o mesmo endereço MAC, todos os pacotes enviados para esse endereço são enviados para todos os membros do cluster. No entanto, um problema com esta configuração é quando os servidores cluster NLB estão conectados ao mesmo switch, você não pode ter duas portas no switch com o registro do mesmo endereço MAC. O protocolo NLB resolve este problema mascarando o endereço MAC do cluster. O Switch olha para o endereço MAC de origem no cabeçalho do quadro Ethernet, a fim de saber quais os endereços MAC são associados com suas portas. O NLB cria um endereço MAC falso e atribui esse falso endereço MAC para cada servidor no cluster NLB. O NLB atribui a cada servidor NLB um endereço MAC falso diferente com base na identificação do membro.

Por exemplo, o endereço MAC do cluster NLB é o 00-bf-ac-10-00-01. O NLB no modo unicast leva o endereço MAC do cluster e, para cada membro do cluster, o NLB muda o segundo octeto do membro NLB. Por exemplo, o servidor 1 terá como falso endereço MAC 00-01-ac-10-00-01, o server com o ID 2 tem o falso endereço MAC 00-02-ac-10-00-01, assim por diante. Se um único endereço MAC está registrado em cada porta do switch, os pacotes não são entregues a todos os membros do cluster, em vez disso os pacotes são enviados para as portas de individuais com base no endereço MAC atribuído a essa porta. Para fazer os quadros serem entregues a todos os membros do cluster, o NLB registra um MAC diferente  e utiliza nas mensagens ARP em broadcast. Quando o roteador envia uma solicitação ARP para o endereço MAC do endereço IP virtual, a resposta contém no cabeçalho ARP com o endereço MAC real do  cluster NLB  00-bf-ac-10-00-01, como por exemplo citado acima e não o endereço MAC falso.

Os clientes então utilizam o endereço MAC no cabeçalho ARP, não o cabeçalho Ethernet para comunicar-se com o servidor. O switch usa o endereço MAC no cabeçalho Ethernet, não o cabeçalho ARP. A questão é quando um cliente envia um pacote para o cluster NLB com endereço MAC de destino como cluster de endereço MAC 00-bf-ac-10-00-01, o switch olha para a tabela MAC para o endereço MAC 00-bf-ac-10-00-01. Como não há porta registrada com o endereço do cluster NLB 00-bf-ac-10-00-01, o quadro é entregue a todas as portas. Isso força o Switch a encaminhar o quadro para toads as portas ocasionando flooding e atrapalhando o desempenho da rede.

Uma solução para mudar o comportamento de flooding é colocar um hub na frente dos membros do cluster NLB e, em seguida,um uplink do hub para uma porta do switch.  Isso evita o problema de duas portas de switch registrando o mesmo endereço MAC. Quando o cliente envia pacotes para o endereço MAC do cluster NLB, os pacotes podem ir diretamente para a porta do switch conectado ao hub e, em seguida, para os membros do cluster NLB.

Multicast
Quando você usa o método de multicast, cada servidor do cluster mantém o endereço MAC original do da placa de rede. Além do endereço MAC original, é também atribuído um endereço MAC em multicast, que é compartilhado por todos os servidores de cluster. As requisições de entrada do cliente são enviadas para todos os servidores do cluster usando o endereço MAC em multicast.

No entanto, no modo multicast, a resposta ARP (ARP reply) enviada por um servidor do cluster em resposta a uma requisição ARP, mapeia o endereço IP unicast do cluster para endereços MAC em multicast. Tal mapeamento no ARP reply é rejeitado por alguns roteadores (ou Switch L3). Dessa forma os administradores devem adicionar uma entrada ARP estática no roteador para mapear o Endereço IP do cluster ao seu MAC Address.

Configurando NLB Multicast mode com o mapeamento estático  para Comware

  1. Desabilite a função de validação do ARP.: undo arp check enable
    Obs: configure nos Switches L3 e L2 (que os servidores do cluster estejam conectados).
  2. Configure uma entrada estática para o ARP :. arp static ip-address mac-address vlan-id interface-type interface-number .
    Obs: Para Switches com função L3 na topologia.
  3. Configure uma entrada multicast MAC estática: mac-address multicast mac-address interface interface-list vlan vlan-id
    Obs: dependendo do cenário, configure nos Switches L3 (porta para o trunk com o Switch de acesso) e L2 (porta para os servidores)

Resumo

Modo Unicast : O  NLB atribui a cada membro de cluster um endereço MAC comum, que é o endereço MAC do cluster  e muda o endereço MAC de origem de cada pacote enviado pelos servidores do cluster . Assim, o switch não pode adicionar o endereço MAC do cluster à sua tabela MAC . Dessa forma o  endereço MAC é desconhecido e os pacotes destinados ao Cluster são encaminhados para todas as portas do Switch.

Modo Multicast : O NLB usa um endereço MAC multicast que é um endereço MAC virtual para as máquinas do Cluster.

Configuração

No configuration guide do Switch HPN 10500 há uma configuração mais simples sem o mapeamento da entrada ARP no Switch (o link do arquivo de configuração está nas referências abaixo).

O cluster NLB está na VLAN 10 enquanto os clientes estão na VLAN 20. O Switch fará o roteamento entre VLANs e o encaminhamento do tráfego NLB em modo multicast
NLB Config Guide example

Obs: iniciaremos a configuração com todas as portas configuradas nas respectivas VLANs e as máquinas utilizando o Switch como gateway

 

<Switch> system-view
[Switch] interface vlan-interface 10
[Switch-Vlan-interface10] ip address 16.1.1.1 255.255.255.0
[Switch-Vlan-interface10] quit
[Switch]
[Switch] interface vlan-interface 20
[Switch-Vlan-interface20] ip address 10.0.0.1 255.255.255.0
[Switch-Vlan-interface20] quit

# Desabilitando a validação ARP
[Switch] undo arp check enable
# Configurando a entrada MAC multicast estática
[Switch] mac-address multicast 03bf-1001-0164 interface GigabitEthernet 4/0/2 GigabitEthernet 4/0/3 vlan 10

Referências

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/107995-microsoft-nlb.html

http://h10032.www1.hp.com/ctg/Manual/c03796252

Obs: Se vocês tiverem algum outro script ou experiência com esse tipo de cenário, por favor deixe um comentário 🙂

Se o link estiver quebrado, também deixe uma mensagem.

Switches 3Com 4800G – IGMP Snooping

Diego DiasLeave a comment
Publicado originalmente em 3 DE OUTUBRO DE 2010

O Protocolo IGMP permite que hosts registrem-se a um Grupo Multicast encaminhando/ respondendo mensagens IGMP ao Roteador da LAN. Roteadores e Switches de Camada 3 escutam as mensagens IGMP para encaminhar o fluxo para o segmento solicitante.
 Após o Switch Core receber o tráfego Multicast do Servidor, ele precisa decidir sobre o encaminhamento do tráfego Multicast nos links Ethernet (após satisfazer as seguintes questões):
  • Existe algum usuário conectado em meus links Ethernet que está interessado em receber o tráfego Multicast?
  • Se nenhum host está interessado em receber o tráfego Multicast, haveria necessidade de encaminhar o tráfego e consumir banda?
  • Se existe um host interessado em receber o tráfego, onde ele está localizado?

Em cima dessas questões, o IGMP foi desenvolvido para estabelecer encaminhamento do tráfego Multicast entre o Roteador e/ou Switch de Camada 3 e as máquinas com as mensagens Join, Query e Leave.

JOIN
Antes de o computador receber o tráfego Multicast, ele necessita efetuar um “Join” no grupo Multicast encaminhando um IGMP Report ao Roteador. O Roteador IGMP encaminha mensagens IGMP Query periodicamente esperando a resposta IGMP Report de algum host para continuar encaminhando tráfego Multicast.

Obs: O computador pode encaminhar um Join antes sem esperar a mensagem IGMP Query do Roteador!

LEAVE
A partir do IGMP versão 2, os hosts que não querem receber o trafego Multicast encaminham uma mensagem IGMP Leave. O Roteador Multicast, encaminha uma nova mensagem IGMP Query questionando se há mais algum computador na rede interessado no tráfego, se não houver resposta, o tráfego Multicast não será encaminhado para o segmento.

IGMP Snooping
Por default, após o Join de um host ao grupo Multicast, o tráfego é inundado para todas as portas dos Switches de acesso que pertencem a VLAN que efetuou a requisição.

  1. O Servidor da VLAN 10 inicia a transmissão do tráfego Multicast
  2.  ALGUNS Hosts da VLAN 192, encaminham uma mensagem IGMP Report (Join) para recebimento de tráfego do Grupo Multicast 239.1.1.1
  3.   O Fluxo Multicast é encaminhado para todas as portas da VLAN 192, incluindo as portas das máquinas que não estão interessadas no conteúdo.

Para evitar a inundação do tráfego Multicast ( transformando o comportamento do tráfego em Broadcast), a feature IGMP-Snooping monitora as mensagens IGMP Report, Query e Leave para adicionar somente as interfaces que desejam receber o fluxo na tabela CAM.

Dessa forma o IGMP Snooping permite aos Switches encaminhar o tráfego Multicast somente para os grupos Multicasts desejados, evitando desperdício de banda e otimizando os Recursos.

 

Comandos do Switch 4800G

#
igmp-snooping
!Habilitando o IGMP-Snooping globalmente

vlan 192
 igmp-snooping enable
!Habilitando o IGMP-Snooping na VLAN 192.

Display

 [4800G] display igmp-snooping group vlan 192
  Total 1 IP Group(s).
  Total 1 IP Source(s).
  Total 1 MAC Group(s).
 Port flags: D-Dynamic port, S-Static port, C-Copy port
  Subvlan flags: R-Real VLAN, C-Copy VLAN
  Vlan(id):1.
    Total 1 IP Group(s). Router port(s):total 1 port.
            GE1/0/48              (D)
! Interface identificada como Porta de conexão com o Roteador,
onde as mensagens Query são geradas
    Total 2 IP Source(s).
    Total 1 MAC Group(s).
    IP group(s):the following ip group(s) match to one mac group.
!Interfaces que efetuaram a solicitação para recebimento de fluxo Multicast
      IP group address:239.1.1.1
        (0.0.0.0, 239.1.1.1):
          Host port(s):total 2 port.

            GE1/0/34              (D)
            GE1/0/38              (D)
    MAC group(s):
          Host port(s):total 2 port.
            GE1/0/34
            GE1/0/38
      MAC group address:0100-5e01-0101
!Endereço MAC do Grupo Multicast e tabela de encaminhamento

Obs: Para configuração do Roteamento Multicast entre VLANs, consultem os tópicos Multicast do Blog ou deixem um comentário!

Abraços a todos!

Referência; CCIE Routing and Switching Exam Certification Guide, 4rd Edition [Odom, Healy, Mehta]

 

 

Switches 3Com 5500 – Configurando Roteamento Multicast com PIM DM

Diego DiasLeave a comment

Publicado originalmente em 10 DE SETEMBRO DE 2010

Durante um evento na sala de reunião da Empresa X, a Diretoria solicitou a equipe de TI que a reunião fosse retransmitida e para o departamento de Marketing da Empresa.

Como solução para a solicitação os Analistas decidiram utilizar o Roteamento Multicast para exibir o vídeo somente para os funcionários do departamento interessados, ao invés de encaminhar o vídeo para toda a empresa!

Para exibição do Stream (Fluxo)de Vídeo foi utilizado o endereço de Multicast Privado 239.1.1.1. Os Hosts da VLAN Marketing que estiverem interessados em visualizar o conteúdo precisarão buscar o endereço informado.

Segue abaixo a configuração do cenário:

#
multicast routing-enable
! Habilitando o Roteamento Multicast no Switch L3
#
vlan 10
#
vlan 172
#
vlan 192
#
interface Vlan-interface10
ip address 10.0.0.1 255.255.255.0 
pim dm
! Configurando a Interface VLAN para encaminhar mensagens Multicast utilizando o protocolo de Roteamento Multicast PIM Dense Mode
#
interface Vlan-interface172
ip address 172.31.1.1 255.255.255.0
igmp enable
! O Protocolo IGMP é responsável por identificar se os hosts da VLAN 172
querem ou não visualizar o vídeo Multicast
pim dm
! Configurando a Interface VLAN 172 para encaminhar mensagens Multicast
utilizando o protocol de Roteamento Multicast PIM Dense Mode

Comando Display

display multicast routing-table
Multicast Routing Table
Total 1 entry
(10.0.0.100, 239.1.1.1)
! O host 10.0.0.100 gera o fluxo com o endereço Multicast 239.1.1.1
Uptime: 00:22:15, Timeout in 285 sec
Upstream interface: Vlan-interface10(10.0.0.1)
Downstream interface list:
Vlan-interface172(172.31.1.1) 
.....

Pronto, roteamento Multicast funcionando!