Redhat Enterprise Linux 6 Multicast-Feed

Ich schreibe eine Anwendung, die Multicast-Daten auf einem neuen Redhat Enterprise Linux 6-Server empfängt. Das Support-Team gibt mir eine Anwendung, mit der getestet wird, ob der Server Multicast-Datenfluss erhalten kann.Redhat Enterprise Linux 6 Multicast-Feed

Sobald beginne ich die Testanwendung, und auch tcpdump laufen hat, Ich kann die Multicast-Daten sehen in den kommenden zB

12:58:21.645968 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 729 
12:58:21.648369 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 969 
12:58:21.649406 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 893 
12:58:21.651823 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 604 
12:58:21.654079 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 913 
12:58:21.656724 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1320 
12:58:21.658194 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 124 
12:58:21.658226 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 217 
12:58:21.658348 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 182 
12:58:21.658625 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1014 
12:58:21.659592 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 135 
12:58:21.659842 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660674 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660743 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.662327 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.669154 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 161 
12:58:21.669365 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 166 
12:58:21.670792 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670796 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670798 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670799 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49

Aber die Anwendung nicht in der Lage jeden Datenfluss zu holen, dh Die Anwendung wird so ausgeführt, als wäre die Multicast-Datensubskription nicht erfolgreich.

Das Support-Team versichert mir, dass es kein Problem mit der Testanwendung gibt, weil es auf anderen Servern gut läuft. Da ich einen neuen Server habe, ist es möglich, dass einige Einstellungen auf dem Server nicht richtig sind.

Ich wundere mich, welche Linux-Einstellungen ich suchen sollte, die potenziell die Anwendung stoppen kann die Multicast-Daten erhalten, auch wenn tcpdump die Daten sehen kann. Fehlende Bibliotheken oder Pakete?

Danke.

Quelle

2012-03-26 2607

Zunächst sollte geprüft werden, ob RHEL 6 Multicast-Unterstützung auf Kernel-Ebene aktiviert hat. (wahrscheinlich, aber RHEL 6 steht nicht zur Verfügung) Stellen Sie sicher, dass die Datei/proc/net/igmp vorhanden ist.

Überprüfen Sie auch, dass der Multicast-Adressbereich an die erwartete Schnittstelle weitergeleitet wird. Wenn das falsch ist, können Sie einige interessante Symptome haben, wo Sie Multicast nur erhalten, während tcpdump (Promiscuous) Pakete schnüffelt. Dies kann auch der Fall sein, wenn Ihr NIC Multicast nicht ordnungsgemäß unterstützt. Einige ältere NICs müssen möglicherweise auch auf den Promiscuous-Modus gesetzt werden, um Multicast zu empfangen, unabhängig von der Multicast-Einstellung, die in ifconfig angezeigt wird.

Eine andere Sache zu tun ist, den Inhalt der/proc/net/igmp-Datei zu überprüfen, während Ihre Testanwendung ausgeführt wird. Die Datei/proc/net/igmp enthält eine Liste aller Multicast-Gruppenadressen, die der Server aktiv empfängt. Wenn in der Spalte "Gruppe" ein Eintrag vorhanden ist, der der Multicast-Gruppenadresse entspricht, die die Testanwendung empfangen soll (in Ihrem Fall 238.6.6.36 und 238.230.230.100), dann haben wahrscheinlich die Socket-Optionen IP_ADD_MEMBERSHIP (oder IP_ADD_SOURCE_MEMBERSHIP) wurde korrekt und auf der richtigen NIC aufgerufen. Beachten Sie, dass die Gruppenspalte die Multicastgruppenadressen in hex und rückwärts auflistet - 238.6.6.36 wird dann als 240606EE aufgelistet.

Ihre Situation kann komplizierter sein, wenn Sie einen Multicast-Router (z. B. Xorp, igmpproxy) auf demselben Computer haben, auf dem Sie die Testanwendung ausführen. Wenn dies der Fall ist, sollten Sie auch die Dateien/proc/net/ip_mr_vif und/proc/net/ip_mr_cache untersuchen, um sicherzustellen, dass entsprechende Einträge vorhanden sind.

Quelle

2012-03-29 00:00:25

Vielen Dank Andrew für Ihre freundliche Antwort. Da ich kein Netzwerkexperte bin, werde ich dies an das Support-Team weiterleiten. – 2607

Nützliche Informationen, habe das gleiche Problem. Wusste nicht über/proc/net/igmp, sondern verwendete netstat -g. Immer noch nicht das Problem gefunden – easytiger

Ich hatte ein ähnliches Problem auf einer RHEL 6 Maschine. Ich habe es gelöst, indem ich den erforderlichen UDP-Port zu den erlaubten Ports durch die Firewall hinzugefügt habe. Versuchen Sie, den udp-Port 50002 hinzuzufügen.

Quelle

2012-03-28 21:59:20

Vielen Dank für Ihre Antwort.Sowohl selinux als auch iptable sind auf dem Server deaktiviert. Was passiert, ist, dass vor dem Anwendungsprozess Multicast-Daten ein Snapshot von einer anderen Unicast-Datenquelle benötigt wird und dass der Unicast-Quellport nicht geöffnet ist. – 2607

Bitte überprüfen Sie den Schalter level.In meinem Fall war ich mit Clustering fest. Mein Cluster funktioniert nur bei Mulitcast. Aber ich war mit einem Paket in Multicast konfrontiert. Es war zu seltsam für mich. Aber irgendwann bekam ich die Lösung von einem meiner besten Freunde (google). Ich habe gerade deaktiviert IGMP auf meinem Schalter Ebene und es funktioniert gut ..

Quelle

2012-12-11 12:49:37 user1894704

Antwort

Verwandte Themen