☰

IGMP v3 JOIN enviado, mas nenhum tráfego do switch

tag-icon • tag-icon multicast cisco
IGMP v3 JOIN enviado, mas nenhum tráfego do switch

Estou tentando ingressar em um fluxo multicast IGMP de uma máquina Centos 8, mas depois de enviar um JOIN, não há tráfego vindo do switch.

Conexão simples:

MUX <-----------> cisco3850 <--------> Centos8
192.168.117.13                         192.168.117.21

O switch upstream (cisco catalisador 3850) é alimentado com um MPEG-TS para 239.1.1.1:4000 do MUX.

Eu tentei socatmeu próprio programa para abrir um soquete, ingressar no stream e manter o soquete aberto. Ambos enviam a mesma mensagem de junção IGMP confirmada pelo wireshark:

Internet Group Management Protocol
    [IGMP Version: 3]
    Type: Membership Report (0x22)
    Reserved: 00
    Checksum: 0xe9fb [correct]
    [Checksum Status: Good]
    Reserved: 0000
    Num Group Records: 1
    Group Record : 239.1.1.1  Change To Exclude Mode
        Record Type: Change To Exclude Mode (4)
        Aux Data Len: 0
        Num Src: 0
        Multicast Address: 239.1.1.1

Usando ip route addcriei rotas para grupos multicast para a interface:

224.0.0.0/4 dev eth1 scope link
225.0.0.0/8 dev eth1 scope link
239.0.0.0/8 dev eth1 scope link

e cat /proc/net/igmpmostra que o grupo se juntou:

cat /proc/net/igmp
Idx     Device    : Count Querier       Group    Users Timer    Reporter
3       eth1      :     2      V3
                                030101E1     1 0:00000000               0
                                010000E0     1 0:00000000               0

EUsuspeitoeste é um problema do switch e não do Linux, mas o cliente (que possui o switch) diz que está tudo bem.

O que mais posso fazer no lado do Linux para investigar/corrigir esse problema?

Se for um problema no switch, o que acontecerá? O que precisa ser configurado lá? (precisa explicar ao cliente)

Para referência, meu programa que une e mantém o soquete aberto se parece com:

// Error checking omitted for brevity
fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes);

memset(&saddr, 0, sizeof(saddr));
saddr.sin_family      = PF_INET;
saddr.sin_addr.s_addr = mcastAddr;
saddr.sin_port        = htons(port);

bind(fd, (struct sockaddr *)&saddr, sizeof(saddr);

struct ip_mreq mcastReq;
mcastReq.imr_multiaddr.s_addr = mcastAddr;
&mcastReq.imr_interface.s_addr = interfaceAddr;

setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mcastReq, sizeof(mcastReq);

Responder1

No final, o switch do cliente não pôde/não quis ativar o IGMPv3, então configuramos nossa máquina para usar o IGMP v2 criando um arquivo em /etc/sysctl.d.

O JOIN funcionou, mas o Linux não respondeu às consultas de associação multicast, então o switch interrompeu o fluxo após 1-2 minutos (mesmo que tivéssemos net.ipv4.conf.default.rp_filterdefinido como zero).

Acontece que para desabilitar totalmente a validação do caminho de retorno, precisávamos definir todas as rp_filterconfigurações como zero (incluindo listar explicitamente a interface)

# Set IGMP Version for eth1
# Set to '2' or '3' depending on what is enabled in the switch
net.ipv4.conf.eth1.force_igmp_version = 2

# Disable source route verification
# In addition to 90-torque.conf, also explicitly set eth1 to ignore
# return path validation
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0

informação relacionada