Press "Enter" to skip to content

Protocolo Multicast e IGMP

0

O Multicast é usado para enviar as mesmas informações para várias estações (por exemplo, um canal de áudio ou vídeo). Oferece muitas vantagens sobre outras alternativas:

  • Unicast: Se a mesma informação é enviada para todas as estações como tráfego unicast, uma grande quantidade de largura de banda é necessária na rede, e o servidor também deve ter uma multidão de sessões abertas, uma com cada máquina.
  • Broadcast: se transmitido, os roteadores devem passar esse tráfego e, idealmente, o tráfego de broadcast deve estar contido na LAN. Além disso, se uma estação não deseja receber esse tráfego, ela deve processar todo o quadro de transmissão, o que leva a uma menor largura de banda disponível e uma carga maior, ao ter que processá-lo.

O multicast envia uma única cópia de cada pacote, que é reproduzido conforme necessário, para alcançar apenas os clientes que o solicitaram. (RFC 1112)

O IP Multicast possui as seguintes características:

  • Permite o envio de um pacote para um grupo de hosts identificados por um único endereço IP.
  • Entrega do pacote com a mesma confiabilidade que o resto dos pacotes IP.
  • Suporta a adição de novos hosts ao grupo no modo dinâmico.
  • Suporta qualquer membro, independentemente do número deles e sua localização.
  • Suporta que um host esteja em vários grupos simultaneamente
  • Suporta um único endereço para múltiplas aplicações.
  • O servidor não conhece a identidade real dos clientes.

ENDEREÇO MULTICAST

A classe D de endereços IP é reservada para multicast (de 224.0.0.0 a 239.255.255.255). O intervalo 224.0.0.x é reservado para propósitos locais, como administração (na tabela há alguns exemplos), e os roteadores não os encaminham. O intervalo 239.x.x.x é reservado para o escopo administrativo (uma zona onde você não pode transmitir com outros endereços, para garantir alta velocidade) é semelhante a uma classe privada.

Endereço Utilização
224.0.0.1 Todos los hosts de una subred
224.0.0.2 Todos los routers de una subred
224.0.0.4 Todos los routers DVMRP (Distance Vector Multicast Routing Protocol)
224.0.0.5 Todos los routers OSPF
224.0.0.6 Todos los routers OSPF designados
224.0.0.9 Todos los routers RIP
224.0.0.13 Todos los routers PIM (Protocol Independent Multicast)

Os endereços multicast podem ser dinâmicos (o cliente solicita esse endereço apenas para receber as informações do grupo) ou estático (o cliente sempre responde a esse endereço)

Para que o tráfego multicast funcione bem em redes locais, o endereço MAC das estações que estão nesses grupos deve ser identificado, pois, caso contrário, o protocolo ARP identificaria o mesmo endereço MAC com dois endereços IP. A maneira de mapear esses endereços é a seguinte:

IP 224 10 8 5
11100000 0 0001010 00001000 00000101
MAC 00000001 00000000 01011110 0 0001010 00001000 00000101
  • Os primeiros bytes do MAC são 01: 00: 5E
  • O próximo bit é um 0
    Os restantes bits são definidos da mesma forma que os últimos do endereço IP Multicast

Existe o risco de existirem vários endereços MAC idênticos dentro da mesma LAN (se o primeiro bit do segundo byte do endereço IP for um “1” ou se o primeiro byte for diferente de 224), mas é um risco assumido, por a baixa possibilidade de isso acontecer.

O mesmo host pode pertencer a vários grupos de multicast ao mesmo tempo (até 32), o que terá até 32 endereços multicast MAC. Cabe então aos aplicativos de nível mais alto discriminar a quem os pacotes são direcionados.

PROTOCOLO DE GESTÃO DO GRUPO INTERNET (IGMP)

Para que o tráfego alcance todos os hosts que desejam ingressar no grupo de multicast, é necessário criar a árvore através da qual os quadros fluirão do servidor para os clientes. Esta árvore é composta pelo servidor, pelos roteadores, pelos switches e pelos clientes. Roteadores e switches precisam ter informações sobre os clientes que pertencem ao grupo, por meio de qual interface eles são acessados ​​e se eles são desconectados do grupo ou se mais clientes são segmentados.

Os protocolos IGMP v1 (RFC 1112) e IGMP v2 (RFC 2236) são usados ​​para gerenciar solicitações de clientes para pertencer a um grupo multicast. O IGMP tem dois tipos de pacotes:
• Query: usado para saber quais dispositivos de rede fazem parte de um grupo de multidifusão.
• Relatório: os hosts enviam como resposta a uma consulta informando que fazem parte do grupo.

10.2.1 IGMP v1
Periodicamente, um roteador de multidifusão via LAN enviará um pacote multicast de Consulta para endereçar 224.0.0.1 (todos os hosts) com TTL = 1. Para este pacote irá responder com um relatório de um host da rede local (roteador ou estação) que pertence a este grupo. Quando a consulta é recebida, todos os hosts definem um valor aleatório entre 0 e 10 segundos. Após esse período, o relatório é enviado se o relatório de outra estação não tiver sido recebido antes. O período em que essas consultas são enviadas é definido com o comando ip igmp [interval].

O IGMP v1 tem o número de protocolo 2. Os pacotes são montados em um cabeçalho IP e possuem apenas 8 bytes de carga. Indica se é um relatório ou uma consulta, um cheksum e o grupo multicast.

Quando um cliente deseja fazer parte de um grupo, ele pode enviar diretamente um relatório para o endereço 224.1.1.1 (todos os roteadores do grupo)

A maneira de excluir um grupo de multicast no IGMP v1 é manter o silêncio após receber uma consulta. Quando todas as estações de uma rede local não respondem à consulta, o roteador também mantém silêncio antes das consultas que recebe, apagando-o também do grupo.

IGMP v2

Na frente do IGMP v1, o IGMP v2 permite enviar consultas e relatórios para um grupo específico, em vez de todos juntos. Também implementa uma mensagem específica para deixar um grupo. Você pode definir o tempo máximo para enviar o relatório entre 1 e 10 segundos (no IGMP v1 ele é corrigido). Esse tempo máximo é definido no pacote de consulta.

As mensagens podem ser:
• consulta
• Relatório de um grupo
• Relatório para deixar um grupo
• Versão do relatório 1 (para compatibilidade com o IGMP v1)

Para entrar em um grupo é feito o mesmo que no IGMP v1. Quando um cliente deseja fazer parte de um grupo, ele pode enviar diretamente um relatório para o endereço 224.1.1.1 (todos os roteadores do grupo)

Usando consultas e relatórios, o roteador constrói uma tabela que identifica os membros de cada grupo multicast em cada uma das interfaces. Quando recebe um quadro multicast de um grupo, ele apenas o envia através das interfaces correspondentes.

O IGMP v2 tem um procedimento para selecionar o roteador que pode enviar consultas em uma LAN, que é a que possui o endereço IP mais alto. Quando o processo é iniciado, todos eles enviam consultas, e se um deles escuta uma consulta com um IP de origem maior que o seu, ele pára de enviá-los. O comando show ip igmp interface [interface] indica quem é a consulta designada dessa LAN.

Você também pode enviar consultas para um grupo específico. Embora o endereço para enviar uma consulta geral seja 224.0.0.1, o endereço para enviar uma consulta de um grupo é para o endereço multicast desse grupo.

A manutenção do grupo é feita de maneira semelhante ao IGMP v1, periodicamente, consultas são enviadas para os hosts e o relatório apropriado é esperado deles. No IGMP v2, você pode enviar consultas gerais ou para um grupo específico.

Para sair de um grupo, enquanto no IGMP v1 houve silêncio e nenhum relatório foi enviado, no IGMP v2 uma mensagem “leave” é enviada para o endereço 224.0.0.2 (todos os roteadores) indicando o grupo que você deseja deixar. Quando o querier eleito recebe esta mensagem, envia uma consulta ao grupo multicast em questão, para verificar se ainda existem hosts que desejam pertencer ao grupo. Se ele não receber um relatório no tempo previsto, ele deixará o grupo também.

CISCO GROUP MANAGEMENT PROTOCOL (CGMP)

Se houver um cliente de um grupo conectado a uma interface de um switch, uma vez que o tráfego multicast é enviado para um endereço desconhecido por ele, ele será enviado para todas as portas, tornando as estações conectadas ao mesmo switch que não deseja receber esse tráfego. eles precisam processar as informações para depois descartá-las, além de remover a largura de banda de acesso.

O CGMP é um protocolo cliente / servidor falado entre o roteador e o switch. O Roteador vê todos os pacotes IGMP e pode informar a troca dos hosts pertencentes ao grupo para que ele forme a tabela de encaminhamento. Quando o roteador vê um pacote de controle IGMP (uma junção ou uma licença), ele cria um pacote CGMP e o envia ao comutador, indicando o endereço MAC do cliente, o grupo multicast e se é uma licença ou uma junção. O switch cria sua tabela com base nessas informações para enviar tráfego somente à porta correspondente.

Protocolo Multicast e IGMP

ROUTING MULTICAST

Para rotear as informações do servidor ou dos servidores multicast para todos os clientes, os roteadores criam uma árvore onde serão transportados para o tráfego, deixando possíveis caminhos isolados redundantes para o tráfego multicast, semelhante ao que o Spanning Tree Protocol faz .

Existem duas técnicas para a construção da árvore:

  • Árvore de distribuição de origem: usada quando há apenas um servidor de tráfego multicast. Trata-se de encontrar o caminho mais curto entre o servidor e cada um dos clientes. É baseado no algoritmo RPF (Reverse Path Forwarding). Se o pacote multicast chega na interface através da qual o roteador alcançar o servidor, o pacote é encaminhado em todas as interfaces, exceto para a qual veio. Se chegar através de outra interface diferente, o pacote será rejeitado. Essa interface é chamada de link “pai” e as interfaces de saída são “filhos”. Pode haver mais de uma fonte, mas uma árvore separada é criada para cada uma delas. É melhor para muito tráfego
  • Árvore de distribuição compartilhada: esse tipo de árvore é usado quando existem várias fontes e você deseja criar uma árvore exclusiva para elas. Trata-se de encontrar um ponto que seja o mais próximo possível de todas as fontes e, a partir deste ponto, uma árvore será criada como

A largura de banda dos aplicativos que exigem multicast geralmente é bastante alta (multimídia), por isso, às vezes, é necessário criar um escopo, uma área na qual esse tráfego será contido. Para conseguir isso, você pode gerar tráfego com um TTL dependendo da área em que deseja conter esse tráfego. Alguns desses valores são mostrados na tabela. Você pode configurar um valor de limite TTL em cada interface do roteador, para que, se o pacote tiver um TTL menor ou igual ao limite, o pacote seja descartado.

PROTOCOLOS DE ROUTING MULTICAST

O protocolo de roteamento multicast é responsável por criar as árvores e ativar o encaminhamento dos pacotes multicast. Existem dois tipos de protocolos de roteamento multicast:

Protocolos de Routing Dense Mode: Eles são usados ​​se os clientes forem localizados de maneira densa e se quase todos os membros da rede precisarem desse tipo de tráfego. É sempre uma árvore de fontes. Dentro deste modo, existem os seguintes protocolos de roteamento:

  • DVMRP (protocolo de roteamento de multidifusão de vetor de distância): definido no RFC 1075, é usado no backbone de multicast da Internet (MBONE). Quando um roteador recebe um pacote multicast, ele o envia para todas as interfaces, exceto onde ele chegou. Se um roteador não quiser receber mais tráfego multicast, ele envia uma mensagem de remoção para cima, para que nenhum outro quadro seja enviado a ele. Periodicamente, os pacotes são enviados para alcançar possíveis novos hosts que desejam ser adicionados a um. Ele possui seu próprio protocolo de roteamento unicast, semelhante ao RIP. Os roteadores Cisco falam PIM, mas eles sabem o suficiente sobre o DVMRP para poder alterar rotas e pacotes com esses dispositivos.
  • MOSPF (Multicast Open Shortest Path First) é descrito no RFC 1584, não é compatível com é semelhante ao OSPF falado em uma única área de roteamento (cada roteador conhece a topologia completa da rede), mas é independente de ser utilizado OSPF ou não para o roteamento do tráfego Unicast.
  • PIM DM (Modo Dense Multicast Protocolo Independente): Isto é semelhante ao DVMRP, o tráfego é enviado a todas as interfaces e, em seguida, ele obtém Prunning em que há clientes multicast. Funciona melhor se essas condições forem atendidas:
    • Existem muitos clientes e poucos servidores
    • Servidores e clientes estão nas proximidades
    • O volume de tráfego multicast é alto
    • O tráfego multicast é constante

Os protocolos de roteamento sparse Mode: se os clientes são usados ​​serão localizados de forma dispersa, não significa que há poucos clientes, mas cada roteador terá alguns clientes de volta. Dentro deste modo, existem os seguintes protocolos de roteamento:

  • CBT (Core-Based Tree): Definido no RFC Uma árvore simples é construída independentemente da localização dos servidores. Um roteador faz um núcleo para essa árvore (árvore compartilhada). Os clientes enviam uma solicitação para esse núcleo para fazer parte da árvore. Após o recebimento, ele retorna um reconhecimento e forma o novo ramo da árvore. Se esta mensagem for interceptada por outro roteador diferente do núcleo que já faz parte da árvore, é ele quem envia o reconhecimento e cria o novo ramo.
  • PIM SM (Modo Independente de Difusão Multicast de Protocolo): Um ponto de encontro (um roteador) é definido. Quando um servidor quiser enviar tráfego multicast, ele será enviado para esse ponto de encontro. Quando um cliente quer se juntar ao grupo, ele também é enviado para se encontrar Uma vez que o tráfego começou entre os dois, é a forma ideal e é para ser usado para todas as comunicações. Este protocolo é útil se houver poucos clientes multicast ou se o tráfego multicast for intermitente ou esporádico. PIM é capaz de trabalhar em modo denso para alguns grupos e no modo Modo esparso para outros simultaneamente. Apenas RP (ponto Rendezvous) é necessário no modo sparse

Configuração de roteamento de multicast IP

O primeiro passo é ativar o multicast rotativo no roteador com o comando:

(config)# ip multicast-routing

Para ver a tabela rotativa de multicast de um roteador, ou para analisar os pacotes multicast que são tratados, você pode executar os comandos:

# show ip mroute [grupo] [fuente] [summary] [count] [active kbps] # debug ip mpacket [detail] [acl] [grupo]
  • contagem fornece informações sobre o número de pacotes
  • kbps ativo indica o intervalo de velocidade da transferência multicast
  • acl monitora somente os pacotes dos grupos definidos em uma lista de acesso
  • grupo monitora apenas os pacotes do grupo definido

Ativar o PIM em uma interface

Uma interface pode ser configurada no modo denso, no modo esparso ou no modo esparso-denso. Isso afetará o processamento do roteamento multicast. No modo denso, o roteador irá entender que todos os roteadores conectados irá multicast, exceto clientes que instruíram o modo de outra forma esparsa e o roteador entende que não há clientes multicast, a menos que ele atinja um aplicativo.

Todos os roteadores mantêm uma lista de interfaces de saída multicast (oilist). Uma interface fará parte desta lista se:

  • Um vizinho do PIM é ouvido nessa interface
    Existe um cliente de um grupo de multicast que é alcançado através desta interface
    A interface é configurada manualmente para pertencer ao
    No modo denso, todas as interfaces pertencem ao oilist no início, e modo escasso em tudo. Nesta lista, as interfaces com um estado (S, G), onde S é a fonte e G é o grupo multicast, são anotadas. tráfego para um grupo vai ser enviada se o tipo (*, G) e a partir de uma fonte, se o tipo de (S, *), enquanto que o tráfego de uma fonte de um grupo ser enviada se os dois valores (S são dadas, G).

No modo sparse, um ponto de encontro (RP) é usado para fazer solicitações de associação ao grupo, já que o roteador entende que ninguém quer pertencer a ele no início. A RP anuncia para baixo a existência de um grupo e para cima os possíveis pedidos de acesso a ele. Feito isso, o tráfego multicast passará pelo melhor caminho entre a origem e o destino.

Para configurar o PIM em uma interface, você precisa colocar o comando:

(config-if)# ip pim {dense-mode | sparse-mode | sparse-dense-mode}

No modo esparso-denso, ele será tratado como modo denso se a existência de um ponto de encontro não for detectada. O IGMP v2 é ativado automaticamente quando o PIM é iniciado na interface.

Para ver informações sobre a operação do PIM em uma interface, coloque o comando:

# show ip pim [interface] [contagem]

O parâmetro count especifica se você deseja ver o número de pacotes multicast pelos quais a interface passou

O PIM estabelece um relacionamento próximo com aqueles diretamente conectados à interface. O roteador com o maior endereço IP será o DR (Designated Router), que será responsável por enviar as consultas para a LAN. O comando a seguir exibe diferentes parâmetros do PIM, entre eles, indica quem é o DR dessa LAN:

# show ip pim neighbor [interface]

Configurar un rendezvous point

Se o modo esparso estiver configurado, é necessário definir quem será o RP (ponto Rendezvous). Em roteadores “folha” (conectado diretamente ao servidor ou clientes) deve saber o endereço do RP, embora ele não precisa saber que este é um RP. A configuração nos roteadores “leaf” é:

(config)# ip pim rp-address [IP] [lista-gupo] [override]
  • group-list define o número de uma lista de acesso padrão onde grupos multicast são definidos para os quais serão
  • Substituir Indica que no caso de esta configuração não coincidir com aquela aprendida pelo auto-RP, a configurada prevalecerá

Auto-RP é um protocolo proprietário da Cisco que permite configurar um único elemento de rede como RP, e que este é o anúncio a ser responsável pelos outros elementos da rede. Dessa forma, as inconsistências são evitadas pelas diferentes configurações nos roteadores, especialmente se houver muitos RPs para os grupos. Neste roteador, você precisa configurar:

(config)# ip pim send-rp-announce [interface] scope [TTL] group-list [lista-gupo]

Os candidatos de RP (no qual é definido o comando anterior) para enviar anúncios CISCO-RP-RP ANUNCIAM grupo (224.0.1.39). Um router configurado como agente de mapeamento RP ouve este grupo e decide que será a RP para cada grupo, e envia-o para o grupo CISCO-RP-DESCOBERTA (224.0.1.40) onde routers designados ouvir PIM, e usar as informações recebidas para saber quem É o RP. Para configurar o roteador que funcionará como agente de mapeamento RP, o comando deve ser definido:

(config)# ip pim send-rp-discovery scope [TTL]

Configurar o limite de TTL

A função do limite TTL em uma interface é controlar o raio de ação do tráfego multicast. Se um pacote multicast chega à interface com um TTL maior ou igual ao definido como limite, o pacote é descartado. Se for maior, o TTL é reduzido em 1 e o pacote é enviado. O valor padrão é 0, o que significa que não há limite. O comando para configurá-lo é

(config-if)# ip multicast ttl-treshold [TTL]

Digite um grupo de multicast

Para que um roteador se junte a um grupo multicast, o seguinte comando é definido. Se um roteador pertencer ao grupo, ele poderá responder ao protocolo ICMP para esse grupo, caso contrário, ele somente encaminhará os pacotes.

(config-if)# ip igmp join-group [grupo]

Alterar a versão do IGMP

Os roteadores não detectam automaticamente a versão IGMP que é falada na rede, portanto, é necessário configurá-lo. Basicamente, a versão v2 será definida, a menos que haja hosts ou outros roteadores na rede que só possam falar IGMP v1. A versão v2 é o padrão nos roteadores Cisco. Para ver o atual ou alterá-lo, você pode inserir os comandos:

# show ip igmp interface [interface] (config-if)# ip igmp version [2 | 1]

Ativar CGMP

O CGMP permite que os roteadores estabeleçam comunicação com os switches para indicar as portas, de modo que eles devem retirar o tráfego multicast. Ele só pode ser ativado nas interfaces dos roteadores que possuem o PIM configurado e, por padrão, está desabilitado. Para ativar o CGMP, você deve inserir os seguintes comandos (um no roteador e outro no switch):

(config-if)# ip cgmp
set cgmp enable ( en IOS: (config)# cgmp )

O processo geral é a de ser o roteador que, depois de receber um pacote de licença de um cliente em IGMP v2, gerar uma mensagem de CGMP instruindo o interruptor para bloquear essa porta, mas há uma funcionalidade pela qual o interruptor é capaz de interpretar esse tipo de mensagens e bloquear a porta em si imediatamente (CGMP fast-leave). O comando no comutador para suportar esta funcionalidade é:

set cgmp leave

Os comandos de verificação do protocolo CGMP no switch são:

show cgmp statistics [vlan]
show multicast group cgmp [vlan]

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: