LAGG mit LACP über OpenVPN TAP Tunnel macht Probleme pfSense 2.2.6

Damit erreiche ich es, die Übertragungsrate annähernd zu vervierfachen, und das bereits bei einem einfachen Transfer ohne Multisegmentierung.

Nichts kann eine Einzelleitung beschleunigen außer dem ISP!
Load Balancing = 1 + 1 = 1 + 1 und nicht 2!!!
MLPPP (MPLS) = 1 + 1 + 1 = 3

Derzeit läuft der VPN mit einem statischen LAG mit Roundrobin - ohne irgend welche Probleme.
Auch alle anderen verfügbaren LAG Varianten LB, FO, … laufen in diesem LAG sofort und ohne Zicken.

Round Robin benutzt alle Leitungen gleichzeitig und füllt diese auch alle zu gleichen Teilen.

Lediglich dynamisches LACP anstelle des statischen LAG verweigert mir den Dienst.

LACP active/active = füllt erst eine Leitung und fängt es an die nächste Leitung zu benutzen
LACP active/passive = benutzt nur eine Leitung und wenn diese ausfällt dann erst wird die nächste Leitung benutzt

Zurück zu meiner eigentlichen Frage: Kann LACP in Verbindung mit virtuellen Ethernet TAP's überhaupt
mal in Betrieb gehen, oder nicht?

Nein, denn zum Einen ist das LAG nicht dafür gemacht und zum Anderen ist es auch immer eine zwei
seitige Angelegenheit die an beiden Enden funktionieren muss.

Statisches LAG geht ja auch!

Ich kann auf drei Arten bei mir von der Wohnung vor die Haustür gehen;

Die Treppe benutzen
Den Fahrstuhl benutzen
Aus dem Fenster springen

Aus dem Fenster springen ist am schnellsten nur ich kenne niemanden der es macht!
Und sicherlich funktioniert es es auch, nur es ist eben nicht dafür vorgesehen und immer
wenn man den eigentlichen und auch gängigen Weg verlässt und auf Probleme stößt wird
es in der Regel schwer diese zu beheben und in der Regel werden es auch immer mehr und
nicht weniger Probleme.

Bei mir zieht die Grundverbindung des LACP noch nicht mal auf. Ich sehe auch kein einziges LACPDU über
die Leitungen laufen, und die sind doch dazu nötig, oder irre ich mich da jetzt?

Du irrst Dich nicht, denn warum sollte man jemandem etwas ermöglichen wenn es doch gar nicht
dafür vorgesehen ist!? Wenn man vier Modems (Modulatoren) hat und zwei pfSense als HA Lösung
oder im Cluster laufen lässt kann man vor den pfSense Firewalls einen Switch stellen und dann dort
sicherlich jede pfSense Firewall mittels LAG anbinden, nur das war es dann auch schon.

Vielleicht hat noch jemand ein paar gute Tipps für mich.

Frag Deinen ISP ob er Euch MLPPP (MPLS) als Dienst anbieten kann!
Mietet Euch stärkere Leitungen mit mehr Bandbreite (FTTH/FTTC)
Holt Euch einen LTE Business Zugang auf beiden Seiten für das VPN

Mehr würde mir jetzt spontan nicht einfallen um es richtig zu machen.

l4k3k3m4n

Ich sehe es genauso, eine LAG ist hier der völlig falsche Ansatz.

Muss es denn zwingend eine OpenVPN Brücke sein?
Wenn du ganz normales Routing betreibt lässt sich das viel einfacher lösen.

Ich nutze dafür OSPF.
Ich habe eine LWL Direktverbindung zwischen meinen Standorten und 2 VPN Tunnel als Backup. OSPF über nimmt die Pfadauswahl, wobei ich nur ein Failover einsetze.
Load Balancing wäre aber auch möglich.

Gruß

Wanninger

Nichts kann eine Einzelleitung beschleunigen außer dem ISP!
Load Balancing = 1 + 1 = 1 + 1 und nicht 2!!!
MLPPP (MPLS) = 1 + 1 + 1 = 3

Deshalb habe ich bisher das ganze Spielchen mit vier einzelnen TAP-Tunneln und darüber liegendem LAG RR
bisher realisiert. Ich benutze zum Übertragen der Userdaten dann ja auch den lagg0, der sich bei RR ja auch
bis maximal 4xDSL Bandbreite füllt. Und glaube mir, es werden die Daten mit 8mBit übertragen und nicht
nur mit 2mBit wie eine einzelne ADSL Leitung.

Aus dem Fenster springen ist am schnellsten nur ich kenne niemanden der es macht!
Und sicherlich funktioniert es es auch, nur es ist eben nicht dafür vorgesehen und immer
wenn man den eigentlichen und auch gängigen Weg verlässt und auf Probleme stößt wird
es in der Regel schwer diese zu beheben und in der Regel werden es auch immer mehr und
nicht weniger Probleme.

Du hast mit deinen Ausführungen sicherlich Recht, allerdings betreibe ich diesen Aufstand nicht weil es mir
Spaß macht, sondern weil ich keine andere Möglichkeit habe.
Da wo ich bzw. die beiden Standorte angesiedelt bin/sind, gibt es trotz der ganzen Versprechen unserer
Regierung auch in Zukunft weder einen brauchbaren DSL noch eine vernünftige LTE Verbindung.
Kein VodafoneLTE und auch kein TelekomLTE!!!
Und bis 2020 sind wir noch nicht mal in der Vorplanung mit drin.

Also nutze ich das was eh schon da ist, und mache das Beste draus, was mir im Moment möglich ist.
Auch wenn es unkonventionell ist, und nicht dem entspricht, wofür es eigentlich gedacht ist.

Vielleicht hat noch jemand ein paar gute Tipps für mich.

Frag Deinen ISP ob er Euch MLPPP (MPLS) als Dienst anbieten kann!

Mietet Euch stärkere Leitungen mit mehr Bandbreite (FTTH/FTTC)

Holt Euch einen LTE Business Zugang auf beiden Seiten für das VPN

Mehr würde mir jetzt spontan nicht einfallen um es richtig zu machen.

Wie gesagt:

Kein brauchbares 4G/3G vorhanden - und zwar von keinem unserer großen Anbieter
FTTH/FTTC am Land, wo die VST noch nicht mal weiß wie man VDSL schreibt?
Telekom und MLPPP? Ja, ich kann zu T-Systems gehen, und mal fragen…
Wir sind hier aber kein Unternehmen mit 500 MA wo es vielleicht keine große Rolle
spielt, ob 2000-3000 Euro pro Monat nur für eine dickere Verbindung, mehr bezahlt wird.

Gruß Wanninger

Wanninger

@l4k3k3m4n:

Ich sehe es genauso, eine LAG ist hier der völlig falsche Ansatz.

Muss es denn zwingend eine OpenVPN Brücke sein?
Wenn du ganz normales Routing betreibt lässt sich das viel einfacher lösen.

Ich nutze dafür OSPF.
Ich habe eine LWL Direktverbindung zwischen meinen Standorten und 2 VPN Tunnel als Backup. OSPF über nimmt die Pfadauswahl, wobei ich nur ein Failover einsetze.
Load Balancing wäre aber auch möglich.

Das ist ja alles schön und gut, aber wenn ich nichts anderes zur Verfügung habe, muss ich entweder mit dem leben was ich habe,
oder versuchen das Maximum - auch mit Tricks wenn nötig - heraus zu holen was möglich ist.

Gruß

Wanninger

…in der Zwischenzeit habe ich auch eine mögliche Ursache herausgefunden, warum sich das LACP wehement weigert zu starten.

Eventuell liegt es schlicht daran, dass die TAP Devices nicht die nötigen Interface Options zur Verfügung stellen, wie
physikalische Interfaces.

Ich bleibe jedenfalls dran an dem Thema.

Wenn ich wieder (echte) Erkenntnisse habe, werde ich sie hier posten...

-cu Wanninger

l4k3k3m4n

Du hättest doch nach Tips gefragt? Ich habe dir einen gegeben. Wenn du das nicht umsetzen möchtest, kein Problem für mich 8)

Company Conect wäre noch eine Möglichkeit oder aber gleich eine SDSL Leitung.
Das ihr auf dem Land lebt oder arbeitet ist durch aus nett wenn man an die Gewerbesteuer denkt, nur
dann darf ich mich eben auch nicht beschweren wenn es kein schnelles Internet gibt. Alternativ kann
man noch zu dem OSPF noch VRRP nehmen wenn man es redundant haben möchte.

Deshalb habe ich bisher das ganze Spielchen mit vier einzelnen TAP-Tunneln und darüber liegendem
LAG RR bisher realisiert. Ich benutze zum Übertragen der Userdaten dann ja auch den lagg0, der sich bei RR
ja auch bis maximal 4xDSL Bandbreite füllt. Und glaube mir, es werden die Daten mit 8mBit übertragen und
nicht nur mit 2mBit wie eine einzelne ADSL Leitung.

Das ist aber nur ab dem internen TAP Interface so und nicht am WAN Port der einzelnen Modems!
MLPPP (MLPS) ist das einzige was Dir (Euch) eine "echte" 4 x 2 MBit/s = 8 MBit/s Leitung ermöglicht
und genau wie das LAG (LACP) muss es von beiden Seiten (ISP und Eurem Router) unterstützt werden.

Im MikroTik Forum wird so etwas ca. einmal die Woche nachgefragt weil alle denken das RouterOS kann MLPPP
(MPLS) und dann ginge das genauso wie Du es hier beschreibst, glaube mir bitte es ist nicht so.

Man klann auch versuchen mittels BGP und über VRRP und OSPF das ganze auszugleichen, was aber, wer und
wie erledigt bestimmt nicht zuletzt der ISP der einem auch die Möglichkeit dazu geben muss.

l4k3k3m4n

Er möchte doch kein Load Balacing zum ISP, sondern zwischen 4 Tunneln die seine Standorte verbinden.
Natürlich kann er da z.B. mit OSPF alle Tunnel mit equal cost ausreizen und so die Bandbreite erhöhen.

Wanninger

@l4k3k3m4n:

Er möchte doch kein Load Balacing zum ISP, sondern zwischen 4 Tunneln die seine Standorte verbinden.

Danke! Genau das ist das Thema, und auch nicht "Loadbalancing klassisch" sondern RoundRobin.

Die einzelnen DSL sind und bleiben auf deren Initialgeschwindigkeit von 2,3MBit/s DL zu 2,1MBit/s UL.
NUR die Verbindung zwischen den Standorten kann ich mit meiner Methode eben auf bis zu 8MBit/s aufbohren.
Bis auf die gelegentlichen Holperer funktioniert das mit einem LAG wirklich stabil.
Die 8MBit/s erreiche ich - logischerweise - aber nur dann, wenn ich Roundrobin verwende.

Was ich hier neu versuche, ist lediglich über ein anderes LAG Protokoll (LACP) den Umstand zu minimieren,
dass bei einem statischen LAG dieser einen Ausfall eines Tunnels nicht erkennt, weil dieser ja nicht physikalisch
ausfällt, sondern nur logisch. Das war doch auch ein Grund, warum die IEEE das LACP spezifiziert hat, um
Ausfälle die keinen physikalischen Link-Down mitbringen, ebenfalls erkannt und behandelt werden können.

Ob LACP überhaupt die einzelnen Strecken ähnlich gut wie RoundRobin füllen kann/wird, kann ich natürlich erst
dann bewerten, wenn ich das LACP jemals in Bertrieb bringen sollte.

Womit ich wieder bei meiner ursprünglichen Frage bin…

ohne Grundsatzdiskussion ob es gut oder schlecht ist, einen LAG dafür zu vergewaltigen, oder ob es bessere Varianten
zu kaufen oder zu mieten gibt, was mir alles nichts hilft, weil ich es, selbst wenn ich wolte, hier nicht bekäme, und ich
weiß, ich habe dafür einen schönen Blick in die Landschaft und zahle weniger Steuern - ;) :-X

welchen Grund/Gründe es dafür geben könnte, dass ich das LACP auf TAP Devices nicht etablieren kann, bzw. ob schon
mal jemand auf einem TAP LACP ans Laufen bekommen hat.

Als mögliche Ursache scheint mir hier tatsächlich der TAP wegen seiner verminderten ethernet Funktionalität in Frage zu
kommen, aber das ist noch eher spekulativ als fundiert.

Nachtrag:

@l4k3k3m4n:

Natürlich kann er da z.B. mit OSPF alle Tunnel mit equal cost ausreizen und so die Bandbreite erhöhen.

Mit OSPF bin ich leider nicht so bewandert. Du meinst, ich könnte damit über die vier Tunnel
eine Lastverteilung ähnlich wie RoundRobin erzeugen, und dann auch auf einem Virtuelles Interface
ähnlich dem Bond, die 8MBit/s - am Stück - abgreifen?

–-

l4k3k3m4n

Ja das kannst du machen. Aber OSPF ist ein Routing Protokoll. Da kommst du mit deiner TAP Brücke nicht weit.
Wenn du auf Tunnel umstellen kannst die gerouted werden kannst du es so einsetzen.

Wanninger

@l4k3k3m4n:

Ja das kannst du machen. Aber OSPF ist ein Routing Protokoll. Da kommst du mit deiner TAP Brücke nicht weit.
Wenn du auf Tunnel umstellen kannst die gerouted werden kannst du es so einsetzen.

…das wäre überhaupt kein Problem. Früher, bevor ich die LAG Geschichte konfigurierte, hatte ich auch nur tun's laufen.

Also richte ich vier P2P tun's ein, wo jeder Einzelne eine eigene lokale IP und ein Gegenüber hat.
Soweit noch kein Problem. In der pfSense gibt es ja auch den OSPF zum nachinstallieren.

Kann ich den dafür hernehmen, und worauf muss ich speziell achten?

-Wanninger

l4k3k3m4n

An sich ist OSPF genau so für Load Balancing geeignet.
Siehe http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html

Ich habe kurz Tante Google befragt und die Info gefunden, dass Quagga unter pfsense scheinbar kein LB möglich macht.
Siehe https://forum.pfsense.org/index.php?topic=70742.0
Ist allerdings 2 Jahre alt…

Ich benutze Quagga für pfsense, aber nur für Failover. Das funktioniert wunderbar.
Vielleicht musst du da doch noch weiter recherchieren.

Wanninger

Nachtrag:

Das ganze Thema scheint sich eh zu erledigen, zumindest dann, wenn man auf den PF-2.3 Branch wechseln will.

Hier hat wohl doch der Pragmatismus der Philosophie Platz gemacht.

Soll heißen, dass ab der 2.3 ein Auswählen von Tunneldevices als Member eines LAG nicht mehr unterstützt wird.

Soweit kein Problem, nur leider ist auch in der aktuellsten 2.3 (immer) noch kein ECMP im System/Kernel drin.
Nach meinen Tests mit OSPF - die soweit vielversprechend verliefen - hat eben alles, bis auf ECMP funktioniert. (Auch in der 2.3beta)

Irgendwie schon schade, dass das Eine entfernt wird, und ECMP als Ersatzlösung noch nicht verfügbar ist.

Alternativ könnte ich das Ganze natürlich noch über zwei Linux VMs machen, die sich dann eben auf diesen Part konzentrieren.

Mal sehen…

Gruß -Wanninger

Soll heißen, dass ab der 2.3 ein Auswählen von Tunneldevices als Member eines LAG nicht mehr unterstützt wird.

Und das wir wohl auch seinen Grund haben, oder glaubst Du etwa das man etwas entfernt was die eigene
Distribution anderen ebenbürtig oder gar überlegen macht? Ich freue mich sogar darüber, ob Du es nun
glauben magst oder nicht wahr haben willst, es war so nie für den Einsatz am WAN Interface vorgesehen
und die Internetleitung(en) wurden damit auch nie gebündelt bzw. dessen Durchsatz erhöht oder gesteigert.

Irgendwie schon schade, dass das Eine entfernt wird, und ECMP als Ersatzlösung noch nicht verfügbar ist.

Für alles gibt es eine Roadmap also eine ToDo Liste oder bzw. eine Funktionsliste auf der alles vermerkt
wird wie es demnächst mit pfSense weiter laufen soll oder wird. Und ich bin mir da völlig sicher, dass dort
die Punkte Einzug halten bzw. finden werden die von xyz Prozent aller Nutzer nachgefragt wird oder werden.
Wie zum Beispiel:

Intel QuickAssist
netmap und DPDK
AES-GCM für OpenVPN

Alternativ könnte ich das Ganze natürlich noch über zwei Linux VMs machen, die sich dann eben auf diesen Part konzentrieren.

Wäre auch ein Ansatz.

Man kann auch ein Load balacing mittels Policy based routing in pfSense realisieren und somit alles
via VPN und über alle Internetverbindungen verteilen. Dann ist das Thema auch abgehakt.

JeGr

Irgendwie schon schade, dass das Eine entfernt wird, und ECMP als Ersatzlösung noch nicht verfügbar ist.

Hattest du mal darüber nachgedacht, das Ganze mit entsprechendem Hintergrund in einen ordentlichen Feature Request zu packen bzw. einmal im 2.3Beta Forum nachzuhaken, wie wo warum es entfernt wird und warum ECMP ggf. noch nicht läuft? Es wäre nicht das erste Mal, dass man dann ggf. eine andere Lösung präsentiert bekommt, an die man vielleicht noch nicht gedacht hat, die aber das Gleiche oder etwas Ähnliches realisiert ohne Sachen zu verbiegen? :)

Grüße

Wanninger

@JeGr:

Irgendwie schon schade, dass das Eine entfernt wird, und ECMP als Ersatzlösung noch nicht verfügbar ist.

Hattest du mal darüber nachgedacht, das Ganze mit entsprechendem Hintergrund in einen ordentlichen Feature Request zu packen bzw. einmal im 2.3Beta Forum nachzuhaken, wie wo warum es entfernt wird und warum ECMP ggf. noch nicht läuft? Es wäre nicht das erste Mal, dass man dann ggf. eine andere Lösung präsentiert bekommt, an die man vielleicht noch nicht gedacht hat, die aber das Gleiche oder etwas Ähnliches realisiert ohne Sachen zu verbiegen? :)

…danke der Nachfrage. Das bzw. etwas Ähnliches habe ich bereits gestern schon gemacht.

In einem älteren Thread (vor PFsense 2.2) habe ich gelesen, dass ECMP geplant ist und demnächst eingebaut werden soll, aber nicht mit hoher Prio.
Nachdem ich bei Tests mit OSPF in PFS-2.2.6 feststellte, dass ECMP noch nicht läuft, habe ich es mit der 2.3beta nochmal versucht. Auch hier bekam
ich kein ECMP. Deshalb habe ich auch im 2.3 Beta Forum mal die Frage nach dem aktuellen Zustand des ECMP gestellt.

Bei der Gelegenheit ist mir dann auch aufgefallen, dass meine bisher laufende Konfig in der 2.3 Beta nicht mehr funktioniert, weil sich mit den TAP Devices kein
LAGG mehr konfigurieren ließ. Das geht aber noch weiter, denn es lässt sich auch mit normalen Ethernet Interfaces kein LAGG mehr konfigurieren.

Zu diesem Punkt habe ich ebenfalls einen Thread im 2.3 Beta Forum gestartet.

Also, es ja nicht so, dass ich nicht doch versuche, gelegentlich mal links und rechts über den Tellerrand raus zu schauen... ;)

Gruß -Wanninger

JeGr

Zu diesem Punkt habe ich ebenfalls einen Thread im 2.3 Beta Forum gestartet.

Bestens, dann wird da ja sicherlich was passieren und drüber diskutiert, dass das mit normalen Interfaces nicht mehr geht, ist ja definitiv ein Fehler. :)

Also, es ja nicht so, dass ich nicht doch versuche, gelegentlich mal links und rechts über den Tellerrand raus zu schauen… ;)

Das war auch gar nicht die Implikation :) Aber es gibt viele hier, die sich hauptsächlich im deutschen Bereich tummeln und sich vielleicht nicht trauen oder meinen ihr Englisch wäre nicht gut genug um wegen einem Problem auch mal ein Topic in einem der anderen Bereiche aufzumachen. Und da es hier halb&halb um ein Feature Request/Bug Report ging, wollte ich es nur anmerken ;)

Grüße

Wanninger

@JeGr

Kann/darf ich als "Otto-Normal-User" im Bugtracker für die 2.3beta wegen des LAGG Fehlers mit "normalen eth Interfaces" auch ein Ticket eröffnen, oder ist das Thema der Devs?

-Wanninger

JeGr

Im Normalfall dürfen User, die im Redmine angemeldet sind (wo sich m.E. jeder registrieren kann) auch Tickets öffnen, es liegt aber am Dev Team, welchen Status sie dem einräumen. Wenn das aber im Beta Forum gepostet wurde, sollte sich das auch jemand ansehen und drauf reagieren, evtl. wäre es dann doppelt gemoppelt. Würde davor ggf. 1-2 Tage abwarten und dann evtl. nochmals mit Hinweis auf den Thread ein Ticket aufmachen. Aber natürlich steht es auch völlig normalen Usern zu Bugs zu posten. Ich bin selbst auch "normaler User" wenngleich ich über unsere Firma im Notfall Zugriff auf das Partnerportal hätte. Aber das ist trotzdem dann kein Sonderstatus ;)

Viele Grüße

JeGr

@wanninger Laut Beta Forum wurde das LAGG Problem gefixt. Vielleicht nochmal testen? :)