Wie erreicht man unter Linux ein Multipath-Routing pro Paket?

Der Linux-Kernel vor Version 3.6 verwendete Routing-Caching für IPv4-Multipath-Routing, was bedeutete, dass das Routing zwischen zwei separaten Leitungen / ISPs recht einfach war. Ab 3.6 wurde der Algorithmus in "Paketweise" geändert, was bedeutete, dass einige Tricks zur Routentabelle / Regel / iptables-Markierung erforderlich waren, um die beiden Leitungen / ISPs zu erreichen.

Wenn Sie jedoch zwei Leitungen mit demselben ISP hatten, die eine einzelne IP auf Paketbasis pro Paket in ausgeglichener / Failover-Weise weiterleiten konnten, konnten Sie ab 3.6 aufgrund von IP6 problemlos eine Leitungsbindung (auf IP-Ebene) erreichen das Routing pro Paket in beide Richtungen.

Ab 4.4 wechselte der Kernel erneut zu einem flussbasierten Lastausgleich basierend auf einem Hash über die Quell- und Zieladressen.

Ich verwende derzeit Kernel 4.4.36 und verwende Multipath-Routing über PPPoE-Verbindungen. Mein Downstream-Verkehr vom ISP wird pro Paket über die beiden separaten Leitungen geleitet (eine IP wird über beide Leitungen weitergeleitet). Dies gibt mir eine Download-Geschwindigkeit, die schneller ist als die Geschwindigkeit einer einzelnen Zeile. Fast die Geschwindigkeit beider Linien addiert. Es funktioniert wirklich gut, Skype-Video, VoIP (UDP), YouTube usw. funktionieren alle hervorragend.

Aufgrund dieser guten Downstream-Erfahrung möchte ich es Upstream ausprobieren, aber mein Upstream-Verkehr wird gemäß dem neueren flussbasierten Algorithmus über beide ppp-Geräte (die dieselbe IP-Adresse haben) geleitet. Dies bedeutet, dass ich keine Upload-Geschwindigkeit erreichen kann, die schneller ist als die Geschwindigkeit einer einzelnen Zeile.

Gibt es eine Möglichkeit, den aktuellen Kernel für die Verwendung des Paketalgorithmus zu konfigurieren? Oder eine andere Methode, um ein Multipath-Routing pro Paket zu erreichen? Muss ich zu einem älteren Kernel zurückkehren (was ich aus verschiedenen anderen Gründen nicht tun möchte)?

Mein ISP unterstützt keine Multi-Link-PPP.

Falls es relevant ist, verwende ich derzeit Arch Linux ARMv7 auf einem Raspberry Pi 3.

— bao7uo
quelle

Das ist eine sehr schlechte Idee. Der Paketausgleich bei L2 (dh MLPPP) enthält genügend Logik, um die Pakete in der richtigen Reihenfolge wieder zusammenzusetzen. Wenn Sie dies über IP ausführen, bleibt eine enorme Chance (wenn nicht sogar eine nahezu sichere) für die Lieferung außerhalb der Reihenfolge. Dies wird eine große Anzahl von Problemen mit langsamen TCP-Sitzungen, insgesamt defektem UDP, Problemen mit jeglichem Echtzeit-Streaming usw. verursachen. Das andere Problem ist, dass selbst wenn Sie Pakete Round-Robin an Ihren ISP senden absolut kein Hinweis darauf, dass sie sich ähnlich auf Sie ausrichten werden.

— rnxrx

@rnxrx danke für deinen Kommentar - habe die Frage bearbeitet, um zusätzliche Details bereitzustellen. Aus meiner Frage: "Der Downstream-Verkehr vom ISP wird pro Paket über die beiden separaten Leitungen geleitet." Der ISP bietet ein Control Panel. Wenn ich eine IP-Adresse auswähle, die über beide Leitungen geleitet werden soll, leiten sie diese perfekt paketübergreifend pro Paket weiter. Funktioniert gut, bei etwa 90% der Gesamtgeschwindigkeit beider Leitungen zusammen und bietet sofortiges Failover. Skype-Video, VOIP-Anrufe, YouTube, BBC-Streaming usw. Alles großartig - Eine so großartige Downstream-Erfahrung bringt mich dazu, Upstream zu versuchen

— bao7uo

Ahh - verstanden ... Haben Sie derzeit zwei eindeutige IP-Adressen (eine pro Verbindung) oder werden diese über zwei parallele Pfade an eine einzelne IP-Adresse (oder ein Subnetz) auf Ihrer Seite weitergeleitet? Wenn Sie irgendeine Art von NAT ausführen, ist es offensichtlich entscheidend, dass es vor diesem Ausgleich auftritt. Wie auch immer - haben Sie sich support.aa.net.uk/… angesehen ? Es verwendet iptables-Erweiterungen, um im Grunde das zu erreichen, was Sie beschreiben, und sollte daher in einigermaßen modernen Kernelversionen ziemlich konsistent sein.

— rnxrx

Danke @rnxrx - ja, ich kann beide Optionen ausführen (zwei eindeutige IPs oder eine einzelne IP über die parallelen Pfade). Ich habe die Single-IP-Option bevorzugt, da sie sinnvoller zu sein schien.

— Bao7uo

Ok, nachdem ich mehr Zeit hatte, dies zu untersuchen, fand ich einen Weg, dies mit Linux TEQL (True Link Equalizer) zu tun. Hier ist ein Link, dem ich lose gefolgt bin, aber mit einigen Verbesserungen.

http://lartc.org/howto/lartc.loadshare.html

So habe ich es auf Arch Linux ARMv7 (Raspberry Pi 3) zum Laufen gebracht.

Beim Booten:

Der folgende Befehl sollte beim Booten ausgeführt werden, um das entsprechende Kernelmodul zu laden.

modprobe sch_teql

Die folgenden Befehle werden auch beim Booten ausgeführt, vorausgesetzt, Sie möchten NAT von einem lokalen Netzwerk auf eth0 ausführen.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

Der FORWARD-Rückverkehr ist auf ppp + und die POSTROUTING-MASKERADE auf teql +, da der ausgehende Verkehr auf teql ausgeht und der Rückverkehr auf ppp zurückkommt.

Wenn ppp-Links auftauchen:

Angenommen, die zu ladenden Links sind ppp. Die folgenden Befehle müssen in einem Skript in einem /etc/ppp/ip-up.d/Skript ausgeführt werden.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

Wo 1.1.1.1befindet sich Ihre öffentliche IP-Adresse für ISPs? Zusätzliche öffentliche IPs können dem teql0-Gerät zugewiesen werden, müssen jedoch nicht den ppp-Geräten zugewiesen werden. In meinem Setup haben die beiden ppp-Links dieselbe IP-Adresse (von pppoe usw. ausgehandelt). Der von ihm manuell zugewiesene teql-Link wie oben gezeigt. Der ISP muss den Datenverkehr für die IP gleichmäßig über beide Verbindungen senden.

Der umgekehrte Pfad ( rp_filter) wird 2im obigen Skript auf (lose) gesetzt, damit die Rückgabepakete nicht verworfen werden, weil sie auf den ppp-Schnittstellen und nicht auf teql0 zurückkommen.

Ich habe es so eingerichtet und es funktioniert perfekt. Sehr leicht! Wenn die Links fehlschlagen, erfolgt ein nahtloses Failover. Wenn sie auftauchen, fangen sie einfach wieder an zu arbeiten. Es scheint, als gäbe es keinen Paketverlust oder keine Verzögerung, wenn ein Failover durchgeführt wird, und keine, wenn es wieder hochfährt.

Außerdem schlug einer der Kommentatoren den folgenden Link vor, der Richtlinienrouting verwendet, mit iptables, um jedes andere Paket usw. zu markieren. Ich werde jedoch in einigen Tagen versuchen, festzustellen, ob es besser als das oben genannte funktioniert, und hier entsprechend Feedback geben.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing

— bao7uo
quelle

Ich habe das Richtlinien-Routing nie ausprobiert, weil TEQL so gut funktioniert hat. Wenn es nicht kaputt ist ...

— bao7uo

Ich versuche das zum Laufen zu bringen. Ich habe das Bonding funktioniert, ich kann die Bonding-Schnittstelle vom Router verwenden. Ich kann das NAT jedoch nicht zum Laufen bringen, der Datenverkehr aus meinem LAN läuft nicht über den

— Bonded

Wenn Sie eine neue Frage zum Serverfehler stellen und aus einem Kommentar darauf verlinken, werde ich versuchen, sie für Sie herauszufinden. Geben Sie so viele Informationen wie möglich wie Schnittstellen- / IP-Konfiguration, Routing-Tabelle, Iptables-Regeln usw. an, es sei denn, Sie können alle Informationen hier in die Kommentare einfügen.

— Bao7uo

PS. habe gerade einen Fehler in meiner Konfiguration bemerkt. es sagte sysctl -w net.ipv4.ip_forwardaber sollte sagen, sysctl -w net.ipv4.ip_forward=1dass ich oben korrigiert habe. Dies würde sicherlich verhindern, dass der Datenverkehr aus dem LAN über die Bonded-Verbindung abläuft.

— Bao7uo

Ich glaube nicht, dass dies dazu geführt hat, dass es für mich nicht mehr funktioniert hat. Ich hatte die Weiterleitung in sysctl aktiviert. Ich versuche jetzt herauszufinden, ob die enorme Anzahl von Paketen, die nicht in Ordnung sind, erwartet wird.

— Andynormancx