Übertragen Sie Multicast (in ein anderes LAN) über das WAN, indem Sie Multicast deaktivieren


7

Meine Server- und Client-Software laufen beide unter Linux.
Der Server sendet Multicast, der Client hört Multicast.

Mein Client muss auf eine andere Site migrieren,
und leider ist Multicast zwischen den beiden Sites nicht zulässig :-(

Wie kann man Multicast zwischen den beiden Standorten übertragen?
- Über TCP oder UDP?
- Welche Tools empfehlen Sie?
- Was ist mit der Latenz?

Ich habe eine gute Antwort zur Cisco- Konfiguration (GRE) erhalten,
aber eines der Netzwerkteams möchte diese nicht überwachen / warten.
=> Wenn die Übertragung unterbrochen wird, verbringt das Support-Team zu viele Stunden, um sie zu verstehen und zu reparieren.
=> Also, was sollte die beste Alternative zu GRE sein?

Gibt es eine Lösung, die auf Linux-Kernelfunktionen
oder Netzwerkkartenfunktionen basiert ? (geringe Latenz ist wichtig)
Anwendungsbeispiele werden geschätzt :-)


Multicast-Kanal: 225.1.0.1:6666


Verwandte Fragen


1
Ich bin kein Experte, aber ich glaube, dass Sie mit Cisco-Routern beispielsweise Multicast zwischen zwei Standorten tunneln können. Ich denke, Sie haben vielleicht bessere Antworten im Superuser-Forum. Hier ist ein Link zu so etwas wie dem, was ich dachte Cisco

1
Sie sollten sich dieses Cisco-Dokument ansehen, das eine ziemlich klare Erklärung und Konfigurationseinstellungen für Cisco-Router enthält. Auch wenn Ihre Hardware nicht von Cisco stammt, erhalten Sie möglicherweise genügend Informationen, um Ihre Hardware zu konfigurieren.
Ex Umbris

Vielen Dank an JimGarrison. Ich werde mich bei meinem Site-Netzwerk-Team erkundigen. Ich befürchte jedoch, dass andere Netzwerkteams mit dieser Konfiguration nicht zufrieden sein werden. Wenn jemand einen Router wechselt oder einen Konfigurationsrouter aktualisiert, ist meine Übertragung möglicherweise unterbrochen ... Und wir verbringen möglicherweise einige Stunden zuvor damit, zu verstehen, was passiert. Meine Übertragung muss nicht länger als ein paar Minuten
unterbrochen werden

Antworten:


4

Ich bin nicht sicher, ob ich Ihre Grafik in Ihrer Frage verstehe, aber soweit ich verstanden habe, müssen Sie Multicast-Pakete über TCP weiterleiten? Eine werkzeugorientierte Lösung kann Folgendes umfassen socat:

Der Multicast-Kanal lautet beispielsweise 224.1.0.1:6666.

Auf dem Server-Host (IP = SS.SS.SS.SS):

$socat -v UDP4-RECVFROM:6666,ip-add-membership=224.1.0.1:CC.CC.CC.CC,fork TCP:destination.hostname:4444

Auf dem Client-Host (IP = CC.CC.CC.CC):

$socat -v TCP-LISTEN:4444,fork UDP4-DATAGRAM:224.1.0.1:6666,range=SS.SS.SS.SS/24

Ich lasse Sie überprüfen, wie Parameter mit dem socatHandbuch eingestellt werden. Sobald Sie Ihre MULTICAST GROUP und die IP-Adressen Ihrer Netzwerkschnittstelle kennen, ist dies ganz einfach. :-)


Aus Neugier scheint diese Lösung einen UDP-Port zum Abhören sowie eine TCP-Verbindung zum Weiterleiten an einen anderen Host zu öffnen. Dies würde bedeuten, dass die Lösung höchstwahrscheinlich eine zweiteilige Lösung ist, ebenso wie Firewall-Änderungen, damit der TCP-Verkehr in das Netzwerk den Socat-Host treffen kann. Ich würde mir vorstellen, dass es schwierig ist, eine IT-Gruppe dazu zu bringen, diesem Setup zuzustimmen.

9

Bei einigen Routern kann Multicast-Verkehr über IP-Netzwerkverbindungen getunnelt werden. Beide Enden des Tunnels müssen entsprechend konfiguriert werden. Insbesondere Cisco unterstützt das Tunneln von Multicast-Verkehr über GRE-Verbindungen. Hier ist ein Artikel darüber, wie Sie dieses Cisco erreichen können


Eines der Netzwerkteams möchte keine spezifische Konfiguration für seine Cisco-Router :-( Daher müssen wir eine Alternative finden, die so effizient ist wie GRE. Zum Beispiel mithilfe von Netzwerkkartenfunktionen oder Linux-Kernelfunktionen ... Haben Sie andere Ideen?
olibre

4

Es ist möglich, aber die Verwendung eines Stream-Protokolls wie TCP ist aus Gründen, die mehrere Überlastungsimplementierungen erfordern (einmal von TCP und ein anderes Mal von Programmen, die versuchen, UDP auf intelligente Weise zu nutzen), keine gute Idee [1] .

Die Möglichkeiten, die Sie haben, sind Tunnellösungen wie OpenVPN + TAP (mit UDP-Transport) oder GRE oder sogar Dinge wie L2TP. [Ich frage mich, ob IPIP / IP6IP6-Tunneling auch funktionieren würde.]


Hey, das ist eine wundervolle Idee :-D Vielen Dank für Ihren Rat zu UDP :-) Bitte können Sie mehr über OpenVPN + TAP und L2TP erzählen. Ich denke, meine Netzwerke werden IP4 für eine Weile verwenden ... Ich nehme an, IPIP / IP6IP6 ist in meinem Fall nicht verwendbar! Wir sehen uns. Cheers
Olibre

Bitte beschreiben Sie Ihre Antwort etwas genauer. Ich schätze die Verwendung / Beispiele ... Sie können zum Beispiel Daten aus Frage (IP1, IP3 ...) wiederverwenden. Ist IPIP / IP6IP6 für vollständige IP6-Netzwerke reserviert?
Olibre

Hi @ jørgensen. Bitte geben Sie weitere Details an. Ich möchte jemandem ein Kopfgeld geben, der ausführlich die beste Alternative zur Routerkonfiguration (GRE) erklärt. Vielen Dank
;-)

3

Linux-Kernel-orientierte Lösung:

mroutedist ein Deamon, der Multicast-Pakete erhält und dem Kernel mitteilt, wohin er sie weiterleiten soll. Sie müssen Ihren Linux-Kernel mit einem bestimmten Patch und den richtigen Optionen neu kompilieren. Konfigurieren Sie dann den mroutedDaemon. Weitere Informationen finden Sie unter Linux-Mrouted-MiniHOWTO.html .

Eine gute Referenz ist das Multicast-Howto , gute Lektüre.

Ich hoffe es hilft.


Wirklich interessant :-) Wissen Sie, ob diese Funktion in Red Hat 5 oder 6 bereits aktiviert ist? Weil mein Administrator wahrscheinlich nicht einverstanden ist, den Red Hat-Kernel in der Produktion zu ändern ...
olibre

1

Steve Miller hat ein gutes Tutorial für Ihr Problem veröffentlicht. Hoffe das wird dir helfen!


Vielen Dank, Kevin. Wie ich in meiner Frage erklärt habe, möchte eines der Netzwerkteams keine Cisco-Router konfigurieren :-( Daher müssen wir eine Alternative finden, die so effizient ist wie GRE. Zum Beispiel mithilfe von Netzwerkkartenfunktionen oder Linux-Kernelfunktionen ... Sie haben eine andere Idee?
Olibre
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.