Kürzlich habe ich einen neuen Ubuntu Server 10.04 eingerichtet und festgestellt, dass mein UDP-Server keine Multicast-Daten mehr sehen kann, die an die Schnittstelle gesendet wurden, selbst nachdem er der Multicast-Gruppe beigetreten ist. Ich habe genau das gleiche Setup auf zwei anderen Ubuntu 8.04.4 LTS-Maschinen und es gibt kein Problem, Daten zu empfangen, nachdem ich derselben Multicast-Gruppe beigetreten bin.
Die Ethernet-Karte ist eine Broadcom netXtreme II BCM5709 und der verwendete Treiber ist:
b $ ethtool -i eth1
driver: bnx2
version: 2.0.2
firmware-version: 5.0.11 NCSI 2.0.5
bus-info: 0000:01:00.1
Ich verwalte meine Multicast-Registrierungen mit smcroute.
b$ smcroute -d
b$ smcroute -j eth1 233.37.54.71
Nach dem Beitritt zur Gruppe zeigt ip maddr die neu hinzugefügte Registrierung an.
b$ ip maddr
1: lo
inet 224.0.0.1
inet6 ff02::1
2: eth0
link 33:33:ff:40:c6:ad
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 224.0.0.1
inet6 ff02::1:ff40:c6ad
inet6 ff02::1
3: eth1
link 01:00:5e:25:36:47
link 01:00:5e:25:36:3e
link 01:00:5e:25:36:3d
link 33:33:ff:40:c6:af
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 233.37.54.71 <------- McastGroup.
inet 224.0.0.1
inet6 ff02::1:ff40:c6af
inet6 ff02::1
Soweit so gut, kann ich sehen, dass ich Daten für diese Multicast-Gruppe erhalte.
b$ sudo tcpdump -i eth1 -s 65534 host 233.37.54.71
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65534 bytes
09:30:09.924337 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:09.947547 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:10.108378 IP 192.164.1.120.58866 > 233.37.54.71.15574: UDP, length 268
09:30:10.196841 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
...
Ich kann auch bestätigen, dass die Schnittstelle Mcast-Pakete empfängt.
b $ ethtool -S eth1 | grep mcast_pack
rx_mcast_packets: 103998
tx_mcast_packets: 33
Hier ist das Problem. Wenn ich versuche, den Datenverkehr mit einem einfachen Ruby-UDP-Server zu erfassen, erhalte ich keine Daten! Hier ist ein einfacher Server, der die an Port 15572 gesendeten Daten liest und die ersten beiden Zeichen druckt. Dies funktioniert auf den beiden 8.04.4 Ubuntu Servern, nicht jedoch auf dem 10.04 Server.
require 'socket'
s = UDPSocket.new
s.bind("", 15572)
5.times do
text, sender = s.recvfrom(2)
puts text
end
Wenn ich ein in Ruby erstelltes UDP-Paket an localhost sende, empfängt der Server es und druckt die ersten beiden Zeichen aus. Ich weiß also, dass der Server oben richtig funktioniert.
irb(main):001:0> require 'socket'
=> true
irb(main):002:0> s = UDPSocket.new
=> #<UDPSocket:0x7f3ccd6615f0>
irb(main):003:0> s.send("I2 XXX", 0, 'localhost', 15572)
Wenn ich die Protokollstatistik überprüfe, sehe ich, dass InMcastPkts nicht zunimmt. Auf den anderen 8.04-Servern im selben Netzwerk wurden innerhalb von 10 Sekunden einige Tausend Pakete empfangen.
b $ netstat -sgu ; sleep 10 ; netstat -sgu
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4654 <--------- Same as below
OutMcastPkts: 3426
InBcastPkts: 9854
InOctets: -1691733021
OutOctets: 51187936
InMcastOctets: 145207
OutMcastOctets: 109680
InBcastOctets: 1246341
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4656 <-------------- Same as above
OutMcastPkts: 3427
InBcastPkts: 9854
InOctets: -1690886265
OutOctets: 51188788
InMcastOctets: 145267
OutMcastOctets: 109712
InBcastOctets: 1246341
Wenn ich versuche, die Benutzeroberfläche in den Promisc-Modus zu versetzen, ändert sich nichts.
An diesem Punkt stecke ich fest. Ich habe bestätigt, dass in der Kernel-Konfiguration Multicast aktiviert ist. Vielleicht gibt es andere Konfigurationsoptionen, die ich überprüfen sollte?
b $ grep CONFIG_IP_MULTICAST /boot/config-2.6.32-23-server
CONFIG_IP_MULTICAST=y
Irgendwelche Gedanken darüber, wohin man von hier aus gehen soll?
rp_filter
und/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
und es begann dann zu arbeiten.Antworten:
In unserem Fall wurde unser Problem durch sysctl-Parameter gelöst, die sich von denen von Maciej unterscheiden.
Bitte beachte, dass ich nicht für das OP spreche (buecking), ich bin auf diesen Beitrag gekommen, weil das Problem durch das grundlegende Detail zusammenhängt (kein Multicast-Verkehr im Userland).
Wir haben eine Anwendung, die an vier Multicast-Adressen gesendete Daten und einen eindeutigen Port pro Multicast-Adresse von einer Appliance liest, die (normalerweise) direkt mit einer Schnittstelle auf dem empfangenden Server verbunden ist.
Wir haben versucht, diese Software auf einem Kundenstandort bereitzustellen, als sie ohne bekannten Grund auf mysteriöse Weise fehlschlug. Versuche, diese Software zu debuggen, führten dazu, dass jeder Systemaufruf überprüft wurde. Letztendlich sagten uns alle dasselbe:
Unsere Software fragt nach Daten, und das Betriebssystem stellt keine zur Verfügung.
Der Multicast-Paketzähler wurde inkrementiert, tcpdump zeigte den Datenverkehr an, der die Box / spezifische Schnittstelle erreichte, aber wir konnten nichts damit anfangen. SELinux war deaktiviert, iptables wurde ausgeführt, es gab jedoch keine Regeln in einer der Tabellen.
Verblüfft waren wir.
Beim zufälligen Herumstöbern haben wir uns Gedanken über die Kernelparameter gemacht, die sysctl verarbeitet, aber keine der dokumentierten Funktionen war besonders relevant, oder wenn sie mit Multicast-Verkehr zu tun hatten, waren sie aktiviert. Oh, und ifconfig listete "MULTICAST" in der Feature-Zeile auf (up, broadcast, running, multicast). Aus Neugier haben wir angeschaut
/etc/sysctl.conf
. Bitte beachten Sie, dass dem Basis-Image dieses Kunden unten ein paar zusätzliche Zeilen hinzugefügt wurden.In unserem Fall hatte der Kunde eingestellt
net.ipv4.all.rp_filter = 1
. rp_filter ist der Route Path-Filter, der (wie ich es verstehe) den gesamten Verkehr ablehnt, der diese Box möglicherweise nicht erreicht haben könnte. Netzwerk-Subnetz-Hopping, der Gedanke ist, dass die Quell-IP gefälscht wird.Dieser Server befand sich in einem 192.168.1 / 24-Subnetz und die Quell-IP-Adresse der Appliance für den Multicast-Verkehr befand sich irgendwo im 10. * Netzwerk. Daher verhinderte der Filter, dass der Server mit dem Datenverkehr etwas Sinnvolles anfing.
Ein paar vom Kunden genehmigte Änderungen;
net.ipv4.eth0.rp_filter = 1
undnet.ipv4.eth1.rp_filter = 0
und wir rannten glücklich.quelle
rp_filter
für unsere 10-Gbit-Netzwerkschnittstelle hat alle unsere UDP-Multicast-Pakete ausgegeben. Den Filter abschalten und alles durchfließen lassen.net.ipv4.all.rp_filter = 0
. Insbesondere mit den Multicast-Daten, die auf eth2 ankamen, musste ich sowohlnet.ipv4.eth2.rp_filter = 0
als auch festlegennet.ipv4.all.rp_filter = 0
.TL / DR Stellen Sie außerdem sicher, dass Ihr Multicast nicht von einem VLAN stammt.
tcpdump -e
würde helfen festzustellen, ob sie es tun.Um ehrlich zu sein, sollte jemand eine Seite mit einer Checkliste von Dingen erstellen, die verhindern können, dass Multicast das Benutzerland erreicht. Ich habe seit ein paar Tagen damit zu kämpfen, und natürlich half nichts, was ich im Internet finden konnte.
Ich konnte nicht nur die Pakete im sehen
tcpdump
, sondern auch andere Multicast-Pakete für andere Hersteller erhalten, nur auf einer anderen Schnittstelle. Der Befehl, mit dem ich getestet habe, ob ich Multicast empfangen kann, war:Der Grund
strace
hier ist , dass ich eigentlich nicht machensocat
die Pakete an die stdout ausdrucken, aber instrace
Ausgabe kann man deutlich sehen , obsocat
Istdaten von dem gebundenen Aufnahmebuchse (es stumm sonst nach ein paar anfänglichen sein werdenselect
Anrufe)rp_filter
sysctl - trifft nicht zu, die Systeme befinden sich im selben IP-Netzwerk (ich habe sie auf den gleichen Wert eingestellt0
, das scheint1
jetzt eine Standardeinstellung zu sein, zumindest für Ubuntu).-e
flag totcpdump
einschließen und nach vlan-Tags suchen. Es ist erforderlich, eine Schnittstelle für das richtige VLAN zu konfigurieren, bevor userland diese Pakete abrufen kann. Das Werbegeschenk für mich war eigentlich, dass die Multicast-Produzenten nicht pingen, aber nicht einmal in den ARP-Cache gelangen, obwohl ich ARP-Antworten deutlich sehen konnte.Um es mit VLAN zum Laufen zu bringen, kann dieser Link hilfreich sein, um das Multicast-Routing zu konfigurieren. (Leider bin ich neu in diesem Bereich, so dass ich aufgrund des Ansehens keine Antwort hinzufügen kann. Daher diese Änderung.)
Folgendes habe ich getan (benutze sudo, wenn nötig):
Auf diese Weise wird eine zusätzliche Schnittstelle für den VLAN-Verkehr mit der VLAN-ID 100 erstellt. Die VLAN-IP ist möglicherweise nicht erforderlich. Dann wird eine Multicast-Adresse für die neue Schnittstelle konfiguriert (01: 00: 5e: 01: 01: 01 ist die Verbindungsschichtadresse für 239.1.1.1) und der gesamte eingehende Multicast-Verkehr wird an eth0_100 gebunden. Ich habe auch alle möglichen Schritte in den obigen Antworten ausgeführt (iptables, rp_filter usw. überprüfen).
quelle
Vielleicht möchten Sie versuchen, sich diese Einstellungen anzusehen:
proc
sysctl.conf
Diese wurden verwendet, um Multicasting in RHEL zu ermöglichen.
Möglicherweise möchten Sie sicherstellen, dass Ihre Firewall den Mutlicast-Verkehr zulässt. wieder mit RHEL habe ich folgendes aktiviert:
quelle
Verwenden Sie einen verwalteten Switch? Einige haben Optionen, um "Broadcast Storms" oder andere Multicast-Probleme zu verhindern, die dazu führen würden, dass sie bestimmte Pakettypen verhindern. Ich würde vorschlagen, einen Blick auf Ihre Switch-Dokumentation zu werfen.
quelle
Sicher über ""? Warum nicht die Multicast-IP-Adresse zum Binden verwenden?
quelle