Kernelquellen / Eigener Kernel / MPTCP

Ich habe vor den Kernel passend für MPTCP vorzubereiten. Im Kern müssen folgenden Sachen angepasst werden. IPV6 darf kein Modul sein. Die MPTCP erweiterung für den Kernel müssen in die Source kopiert werden, und in der Konfig mit zwei parametern aktiviert werden. Die restlichen Anforderungen erfüllt der Astarokernel ohnehin schon. MultiPath TCP - Linux Kernel implementation : Users - Do It Yourself browse 

Wir haben zwei Standorte mit einen Mix aus verschiedenen Leitungstechnologien (DSL,VDSL,FTTH, TV-Kabel, LTE). Stark vereinfacht brauchen wir maximalen Durchsatz und eine Ausfallsicherheit.

Zielkonfiguration ist, dass beide Standorte mit drei Leitungen Aktiv ins Internet gehen. Auf diesen drei Leitung ist MPTCP Aktiv, das führt dazu, wenn ich EINEN VPN Tunnel aufbauen, das dieser über alle drei Leitungne läuft. Der Tunnel weis davon nicht und muss auch nicht dafür konfiguriert werden. Fällt eine Leitung aus, wird es einfach nur langsager. Fallen alle Leitungen aus aktiviert MPTCP einfach die LTE Leitung als Fallback (wenn so konfiguriert). MPTCP arbeitet so, dass es beim Verbinungsaufbau zu erst prüft ob die Gegenstelle Multipath TCP unterstüzt, ist dem so werden so gennte Subflows eingerichtet über die die Daten verteilt übertragen werden.

Im gegensatz zu anderen Bonding oder LAG Varianten setzt MPTCP nicht vorraus, das die Leitung die gleichen Bandbreiten oder Latenzen haben, es konnen verschiende Leitungen verwendet werden, mit den unterschiedlichsten Eckdaten verwendet werden. Der Nutzen ist, das mit annähernd die Summe aller Kapazitäten zur Verfügung steht. MPTCP berücksichtig auch Multiboxen auf dem Routing weg.

Wenn Du eine Lösung kennst, die einfach so mit Bordmittel funktionier, bin ich sofort bei Dir und würde diese Vorziehen.

Ich will schlicht zwei Standorte mit mehrere Leitungen verbinden, um einfach mehr Daten durchzubekommen. Und wenn alle "normalen" Leitungen ausgefallen sind, soll auf LTE ausgewichen werden. 

Den Feature Request habe ich schon vor langer Zeit meine Sterne gegen, am 19 Stück in Summe werden wohl niemanden dazu bewegen es einzubauen.

Den Feature Request habe ich schon vor langer Zeit meine Sterne gegen, am 19 Stück in Summe werden wohl niemanden dazu bewegen es einzubauen.

22

Im Sinne von QM & Co kann ich aber nachvollziehen, warum einige "Kernelfeatures" nicht im UTM Kernel sind, aber es hätte doch Charme ...
 
Alle möglichen multi-dynamic-based-routing-Sachen werden auf vielen UTMs "irgendwie" versucht zu erschlagen, bevor die tatsächlichen und guten Lösungen vielleicht mal Einzug halten. [SIZE="1"]Mich ärgert aber mehr, dass Cisco sowas "nutzt", um den Leuten als "Standard" in Erinnerung zu bleiben und dann auch so kommuniziert wird.[/SIZE]

Den Feature Request habe ich schon vor langer Zeit meine Sterne gegen, am 19 Stück in Summe werden wohl niemanden dazu bewegen es einzubauen.

22

Im Sinne von QM & Co kann ich aber nachvollziehen, warum einige "Kernelfeatures" nicht im UTM Kernel sind, aber es hätte doch Charme ...
 
Alle möglichen multi-dynamic-based-routing-Sachen werden auf vielen UTMs "irgendwie" versucht zu erschlagen, bevor die tatsächlichen und guten Lösungen vielleicht mal Einzug halten. [SIZE="1"]Mich ärgert aber mehr, dass Cisco sowas "nutzt", um den Leuten als "Standard" in Erinnerung zu bleiben und dann auch so kommuniziert wird.[/SIZE]