☰

IGMP v3 JOIN gesendet, aber kein Datenverkehr vom Switch

tag-icon • tag-icon multicast cisco
IGMP v3 JOIN gesendet, aber kein Datenverkehr vom Switch

Ich versuche, einem IGMP-Multicast-Stream von einer Centos 8-Maschine aus beizutreten, aber nach dem Senden eines JOIN kommt kein Datenverkehr vom Switch.

Einfache Verbindung:

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

Der Upstream-Switch (Cisco Catalyst 3850) erhält vom MUX ein MPEG-TS an 239.1.1.1:4000.

Ich habe sowohl socatmit meinem eigenen Programm als auch mit dem Öffnen eines Sockets, dem Verbinden mit dem Stream und dem Offenhalten des Sockets versucht. Beide senden dieselbe IGMP-Verbindungsnachricht, wie von Wireshark bestätigt:

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

Mithilfe von ip route addhabe ich Routen für Multicast-Gruppen zur Schnittstelle erstellt:

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

und cat /proc/net/igmpzeigt an, dass der Gruppe beigetreten ist:

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

ICHverdächtigDies ist eher ein Problem mit dem Switch als ein Linux-Problem, aber der Kunde (dem der Switch gehört) sagt, dass alles in Ordnung ist.

Was kann ich auf der Linux-Seite sonst noch tun, um dieses Problem zu untersuchen/beheben?

Wenn es ein Problem mit dem Switch ist, was dann? Was muss dort konfiguriert werden? (muss dem Kunden erklärt werden)

Zur Referenz sieht mein Programm, das den Socket verbindet und offen hält, folgendermaßen aus:

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

Antwort1

Am Ende konnte/wollte der Kunden-Switch IGMPv3 nicht aktivieren, also haben wir unsere Maschine auf die Verwendung von IGMP v2 eingestellt, indem wir eine Datei unter erstellt haben /etc/sysctl.d.

Der JOIN funktionierte dann, aber Linux antwortete nicht auf Multicast-Mitgliedschaftsanfragen, sodass der Switch den Stream nach 1–2 Minuten abbrach (obwohl wir ihn net.ipv4.conf.default.rp_filterauf Null gesetzt hatten).

Es stellte sich heraus, dass wir zur vollständigen Deaktivierung der Return-Path-Validierung alle rp_filterEinstellungen auf Null setzen mussten (einschließlich der expliziten Auflistung der Schnittstelle).

# 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

verwandte Informationen