☰

IGMP v3 JOIN enviado pero no hay tráfico desde el switch

tag-icon • tag-icon multicast cisco
IGMP v3 JOIN enviado pero no hay tráfico desde el switch

Estoy intentando unirme a una transmisión de multidifusión IGMP desde una máquina Centos 8, pero después de enviar un JOIN, no hay tráfico proveniente del conmutador.

Conexión sencilla:

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

El conmutador aguas arriba (catalizador Cisco 3850) recibe un MPEG-TS a 239.1.1.1:4000 desde el MUX.

Probé ambos socatprogramas y mi propio programa para abrir un socket, unirme a la transmisión y mantener el socket abierto. Ambos envían el mismo mensaje de unión IGMP confirmado por 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 addcreé rutas para grupos de multidifusión a la interfaz:

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

y cat /proc/net/igmpmuestra que el grupo se ha unido:

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

IsospecharEste es un problema con el conmutador más que un problema de Linux, pero el cliente (propietario del conmutador) dice que todo está bien.

¿Qué más puedo hacer en el lado de Linux para investigar/solucionar este problema?

Si es un problema en el interruptor, ¿qué? ¿Qué hay que configurar allí? (es necesario explicarle al cliente)

Como referencia, mi programa que une y mantiene abierto el socket se ve así:

// 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);

Respuesta1

Al final, el conmutador del cliente no pudo/no quiso activar IGMPv3, por lo que configuramos nuestra máquina para usar IGMP v2 creando un archivo en /etc/sysctl.d.

Luego, JOIN funcionó, pero Linux no respondió a las consultas de membresía de multidifusión, por lo que el conmutador interrumpió la transmisión después de 1 o 2 minutos (a pesar de que lo habíamos net.ipv4.conf.default.rp_filterconfigurado en cero.

Resulta que para deshabilitar completamente la validación de la ruta de retorno, necesitábamos establecer todas las rp_filterconfiguraciones en cero (incluida la lista explícita de la interfaz)

# 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

información relacionada