Multicast (IGMP, PIM)

O Multicast é o modelo de comunicação IP que permite a um único remetente transmitir pacotes para um grupo de receptores interessados, de forma eficiente e escalável. Em vez de enviar N cópias para N receptores (Unicast) ou inundar toda a rede (Broadcast), o Multicast envia uma única cópia do pacote, que é replicada apenas nos pontos de bifurcação da árvore de distribuição, alcançando exclusivamente os hosts que manifestaram interesse em receber aquele fluxo.

Esse modelo é a base para aplicações como IPTV corporativo, distribuição de cotações de mercado financeiro em tempo real, replicação de firmware em larga escala e streaming ao vivo em redes gerenciadas. Embora menos visível para o usuário final que o Unicast, o Multicast é fundamental para a eficiência de redes em broadcasting, datacenters e provedores.

1. Endereçamento Multicast

O Multicast IPv4 utiliza a faixa reservada 224.0.0.0/4 (Classe D), definida na RFC 1112, com endereços de 224.0.0.0 a 239.255.255.255. Em IPv6, a faixa equivalente é ff00::/8, definida na RFC 4291. Esses endereços não identificam um host individual, mas sim um grupo lógico que múltiplos hosts podem ingressar dinamicamente.

A. Sub-faixas IPv4

B. Endereços Especiais

• 224.0.0.1 - All Hosts na sub-rede local (todos os hosts que suportam multicast).
• 224.0.0.2 - All Routers na sub-rede local.
• 224.0.0.5 - OSPF AllSPFRouters (todos os roteadores OSPF).
• 224.0.0.6 - OSPF AllDRouters (apenas Designated Routers).
• 224.0.0.9 - RIPv2 (todos os roteadores RIP).
• 224.0.0.10 - IGRP / EIGRP.
• 224.0.0.13 - PIM (All-PIM-Routers).
• 224.0.0.18 - VRRP (Virtual Router Redundancy Protocol).
• 224.0.0.251 - mDNS (Multicast DNS, usado por Bonjour/Avahi).

Em IPv6, equivalências notáveis: ff02::1 (all-nodes), ff02::2 (all-routers), ff02::5 (OSPF), ff02::a (EIGRP), ff02::fb (mDNS).

2. Mapeamento MAC Multicast

Para entregar quadros multicast na camada 2, o IP multicast é mapeado para um MAC especial seguindo a regra OUI 01:00:5E seguido do bit 0 do primeiro octeto IP e o restante dos últimos 23 bits:

IPv4: 239.1.2.3
Hex:  EF:01:02:03
MAC:  01:00:5E:01:02:03

Como apenas 23 bits do IP são usados para formar o MAC (o 25º bit sempre é zero), há sobreposição: 32 endereços IP diferentes mapeiam para o mesmo MAC. Em IPv6, o prefixo é 33:33: seguido dos últimos 32 bits do IPv6.

3. IGMP - Internet Group Management Protocol

O IGMP (IPv4) e o MLD - Multicast Listener Discovery (IPv6) são os protocolos utilizados pelos hosts para informar aos roteadores locais sobre seu interesse em receber tráfego de grupos multicast específicos. São protocolos de camada 3 encapsulados diretamente em IP (protocolo 2 para IGMP, ICMPv6 tipo 130/131/132/143 para MLD).

A. IGMPv1 (RFC 1112)

• Host envia Membership Report para ingressar em um grupo (224.0.0.2 originalmente, depois o próprio endereço do grupo).
• Roteador envia General Query a cada 60s para 224.0.0.1.
• Não há mecanismo explícito de saída (leave) - o host simplesmente para de responder às queries e o grupo expira após 3 ciclos.

B. IGMPv2 (RFC 2236)

• Introduz a mensagem Leave Group, enviada para 224.0.0.2, permitindo saída imediata do grupo.
• Group-Specific Query permite ao roteador perguntar especificamente sobre um grupo antes de removê-lo.
• Suporte a SSM (Source-Specific Multicast) de forma parcial via IGMPv3.

C. IGMPv3 (RFC 3376)

• Adiciona suporte completo a Source-Specific Multicast: o host pode solicitar recepção apenas de fontes específicas (INCLUDE) ou todas exceto algumas (EXCLUDE).
• Mensagens: Membership Report, Group-and-Source-Specific Query.
• Necessário para SSM (232.0.0.0/8).

D. MLD (IPv6)

• MLDv1 (RFC 2710): equivalente ao IGMPv2.
• MLDv2 (RFC 3810): equivalente ao IGMPv3, com suporte a SSM.
• Utiliza mensagens ICMPv6 (tipo 130 Listener Query, 131 Report, 132 Done, 143 v2 Report).

4. PIM - Protocol Independent Multicast

O PIM (RFC 7761 para PIM-SM) é o protocolo de roteamento multicast dominante na internet. É "Protocol Independent" porque aproveita a tabela de roteamento unicast já existente (construída por OSPF, IS-IS, BGP, etc.) para tomar decisões de encaminhamento, sem construir sua própria topologia.

A. Modos de Operação

B. PIM-DM (Dense Mode)

Operação por flood-and-prune: o tráfere é inicialmente inundado para todas as interfaces, e os roteadores que não têm receptores enviam mensagens Prune para remover o ramo da árvore. As árvores são periodicamente reconstruídas (a cada 3 minutos por padrão). Adequado apenas para redes pequenas e densas em receptores, sendo raramente usado em produção atualmente.

C. PIM-SM (Sparse Mode)

Modelo dominante em redes modernas. Utiliza um ponto de encontro central, o RP (Rendezvous Point), para permitir que fontes e receptores se encontrem sem necessidade de flooding. Operação:

1. Receptor → DR (Designated Router): host envia IGMP Membership Report.
2. DR → RP: o DR envia (*,G) Join em direção ao RP, construindo a shared tree (RPT - RP-Tree).
3. Fonte → DR: a fonte começa a transmitir; seu DR encapsula os pacotes em Register messages para o RP.
4. RP → Fonte: o RP envia Register-Stop quando o tráfego começa a fluir nativamente, e constrói uma árvore (S,G) em direção à fonte.
5. Switchover: o DR do receptor pode optar por construir a Shortest-Path Tree (SPT) em direção à fonte, abandonando o caminho via RP. Isso reduz latência e otimiza o caminho.

Estados mantidos nos roteadores: (*,G) (qualquer fonte para o grupo G) e (S,G) (fonte S específica para o grupo G).

D. SSM (Source-Specific Multicast)

Definido para a faixa 232.0.0.0/8 em IPv4 e ff3x::/32 em IPv6, o SSM simplifica o modelo exigindo que o receptor conheça previamente o IP da fonte. Não há necessidade de RP nem de shared tree - apenas árvores (S,G) diretas são construídas. Exige IGMPv3 ou MLDv2 nos hosts.

E. BiDIR-PIM

Variante otimizada para cenários com muitas fontes e muitos receptores (ex: mercado financeiro, videoconferência many-to-many). As árvores são bidirecionais, dispensando o registro de fonte e reduzindo o estado nos roteadores.

5. IGMP Snooping em Switches L2

Como o MAC multicast é o mesmo para todos os hosts do grupo, um switch L2 sem suporte especial tratava multicast como broadcast, inundando todas as portas da VLAN. O IGMP Snooping (RFC 4541) resolve isso: o switch inspeciona passivamente as mensagens IGMP entre hosts e roteadores, mantendo uma tabela que mapeia portas aos grupos multicast.

SW1# show ip igmp snooping groups
Vlan      Group         Type        Version    Port List
-------------------------------------------------------
   10     239.1.1.1     igmp        v2         Gi0/1, Gi0/5, Gi0/12
   10     239.1.1.5     igmp        v3         Gi0/3

A versão avançada, CGMP (Cisco Group Management Protocol), foi substituída pelo snooping padrão. Para PIM snooping, alguns switches de datacenter inspecionam também mensagens PIM Hello e Join/Prune para construir topologia L2 multicast-aware.

6. Aplicações Práticas

• IPTV em provedores: TV ao vivo entregue via multicast na rede do provedor, economizando banda comparado a unicast. Cada canal é um grupo (ex: 239.10.10.5).
• Mercado financeiro: distribuição de cotações Bovespa/NASDAQ em tempo real. Latência crítica, SSM com fontes conhecidas.
• Replicação de software: atualização de firmware em milhares de equipamentos simultaneamente (kiosks, set-top boxes, ATMs).
• Videoconferência H.323/SIP multiponto: MCU e gateways multicast em redes corporativas isoladas.
• RTP (Real-time Transport Protocol): frequentemente sobre multicast em ambientes controlados.

7. Configuração Cisco IOS - Exemplo PIM-SM

! Habilitar multicast routing global
R1(config)# ip multicast-routing

! Configurar PIM sparse-mode nas interfaces
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip pim sparse-mode

! Configurar RP estático
R1(config)# ip pim rp-address 10.10.10.10

! RP também precisa da configuração
RP(config)# interface Loopback0
RP(config-if)# ip pim sparse-mode

! Auto-RP dinâmico (alternativa)
R1(config)# ip pim send-rp-announce Loopback0 scope 31
R1(config)# ip pim send-rp-discovery Loopback0 scope 31

8. Diagnóstico e Troubleshooting

9. Limitações e Considerações

Apesar de eficiente, o Multicast tem adoção limitada na internet pública devido a:

• Complexidade operacional: RP, PIM, IGMP snooping e troubleshooting exigem expertise específico.
• Segurança: grupos podem ser "sequestrados" por receptores não autorizados se não houver ACLs rigorosas; ataques de flooding multicast podem saturar redes.
• Inter-domain multicast: a interconexão entre provedores via MBGP/MSDP era frágil e está em declínio, sendo substituída por SSM e CDN unicast.
• NAT e firewalls: a maioria dos firewalls bloqueia tráfego multicast por padrão, exigindo configuração explícita.

Em datacenters modernos e ambientes Kubernetes, soluções como eBPF multicast, VXLAN multicast replication e Rosenocker multicast têm ganho espaço, demonstrando que o modelo ainda é relevante para casos de uso específicos onde a eficiência 1-para-muitos é crítica.