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

Wanninger

Hallo Gemeinde,

ich habe aktuell zwei pfSensen 2.2.6 mit vier OpenVPN TAP Tunnel und LAGG mit Roundrobin verbunden.
Damit werden zwei Standorte mit vier schmalen DSL Leitungen verbunden.

Das funktioniert soweit auch einwandfrei und stabil, solange die DSL's alle sauber laufen.

In letzter Zeit kam es leider immer öfter vor, dass immer wieder mal ein DSL längere Zeit ausfiel.
Da das statische LAGG'en nur über Link up/down reagiert, erkennt es den fehlenden DSL natürlich nicht,
und ich bekomme insgesamt Probleme.

Ich dachte mir, ich stelle den Bond jetzt einfach auf LACP um, und alles wird gut.

Leider ist es wohl doch nicht so einfach.

Ich habe es bisher noch nicht geschafft, den LAGG mit LACP auf beiden Seiten richtig ans Laufen zu bekommen.

Ein tcpdump auf den TAP devices ovpnxx liefert nicht ein Paket, und auf dem LAGG device kommen nur ARP's

Ifconfig von lagg0 zeigt


lagg0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=80000 <linkstate>ether 00:bd:01:03:00:02
        inet6 fe80::2bd:1ff:fe03:2%lagg0 prefixlen 64 scopeid 0xa 
        inet 1.1.0.252 netmask 0xffffff00 broadcast 1.1.0.255 
        nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
        status: active
        laggproto lacp lagghash l2,l3,l4
        laggport: ovpnc3 flags=0<>
        laggport: ovpnc2 flags=0<></performnud,auto_linklocal></linkstate></up,broadcast,running,simplex,multicast>

Ich habe zum Testen die tap devices auf zwei reduziert.
Die ifconfig Ausgabe sieht auf beiden Seiten gleich aus.

Jede Hilfe/Info ist herzlichst willkommen.

Danke und Gruß

Wanninger
Problem mit LACP zwischen zwei pfSensen.

ich habe aktuell zwei pfSensen 2.2.6 mit vier OpenVPN TAP Tunnel und LAGG mit Roundrobin verbunden.

Also ein LAG (LACP) benutzt man eigentlich nicht am WAN interface, es sei denn es ist ein Switch vor der oder
den pfSense Firewalls platziert. Was man alles machen kann ist das Eine und was man alles machen sollte
ist wiederum etwas ganz anderes. Für so etwas benutzt man im WAN Bereich eher MLPPP (MPLS) oder
"Multi WAN Load Balacing". Bei einem LAG gibt es immer nur eine IP Adresse und wenn die dann genau
zu dem Internetzugang gehört der dann "abgeschmiert" ist bzw. nicht funktioniert hat man gar keine
Verbindung mehr.

Wenn man ein LAG bildet dann ist das genauso wie bei einem VLAN immer eine zwei seitige Angelegenheit
und wenn ein Ende gestört ist ist es auch die die gesamte LAG Konstruktion.

Damit werden zwei Standorte mit vier schmalen DSL Leitungen verbunden.

Zwei auf jeder Seite oder vier auf jeder Seite?

Das funktioniert soweit auch einwandfrei und stabil, solange die DSL's alle sauber laufen.

Siehst Du genau das meinte ich eben damit.

In letzter Zeit kam es leider immer öfter vor, dass immer wieder mal ein DSL längere Zeit ausfiel.
Da das statische LAGG'en nur über Link up/down reagiert, erkennt es den fehlenden DSL natürlich nicht,
und ich bekomme insgesamt Probleme.

Nochmal ein LAG ist eigentlich nur für den LAN Bereich gedacht, im WAN Bereich benutzt man dafür
MLPPP (MPLS) oder Multi WAN Load Balancing.

Ich dachte mir, ich stelle den Bond jetzt einfach auf LACP um, und alles wird gut.

Das denkst nicht nur Du hier im Forum alleine, das denken auch sehr viele Leute im MikroTik und
UBNT Forum! Bonding oder LAG (LACP) ist eigentlich nur für den LAN Bereich gedacht und nicht
für den WAN Bereich. Für ein LAG gibt es leider sehr viele Namen, Bond (Linux), Trunk (Cisco, HP)
Etherchannel (Cisco) und so weiter. Es gibt aber nur zwei Arten von LAGs das dynamische über
LACP und das statische via manueller Einstellung.

Leider ist es wohl doch nicht so einfach.

Einen echten Bond oder LAG am WAN, bekommt man nur mittels MLPPP (MPLS) hin und auch das ist
wieder eine zwei seitige Angelegenheit! Der ISP muss es zwingend als Dienst anbieten und unterstützen
und auch der Router oder die Firewall müssen es unterstützen. Wie zum Beispiel Peplink oder VipriNet
es anbieten.

Ich habe es bisher noch nicht geschafft, den LAGG mit LACP auf beiden Seiten richtig ans Laufen zu bekommen.

Meines Erachtens wird das auch nie so richtig etwas werden da es dafür auch nicht gemacht ist.
Man könnte auf der pfSense vier Gateways anlegen und dann in einer Gateway Gruppe zusammen fassen
und darüber dann das VPN ausbalancieren, das wäre so weit möglich und wenn eine ADSL Verbindung
ausfällt dann wird eben nur noch über die restlichen drei Verbindungen die Last verteilt! Haben die
Verbindungen unterschiedliche Bandbreiten oder Geschwindigkeiten kann man das auch mittels einer
Ratio Einstellung ausgleichen, dann gehen mehr Pakete über die schnellere und weniger Pakete über
die langsameren Internetanbindungen.

Wanninger

Hallo Zusammen, hallo Frank,

erst mal danke für die umfangreichen Ausführungen.

Ich kann das alles nachvollziehen, und gebe Dir im Grundsatz auch recht.

Allerdings muss - hauptsächlich aus Budget Gründen - die perfekte Lösung hinten anstehen.

Die von mir beschriebene Konstellation läuft schon seit langem einwandfrei, und beide Seiten
sind damit zufrieden. Abgesehen von den gelegentlich auftretenden Fehlern in Form von Packetloss,
wenn ein DSL mal holpert.

Es sind im Übrigen 4 identische ADSL auf jeder Seite, die auch den klassischen Internetverkehr über GW-Gruppen,
Loadbalancing und Failover abdecken. Hier ist alles soweit möglich abgesichert.

Lediglich der VPN Verkehr wird über diesen vielleicht etwas exotischen Weg des Bündelns von virtuellen
Ethernetdevices zu einem LAG mit RR zusammen gefasst. Damit erreiche ich es, die Übertragungsrate
annähernd zu vervierfachen, und das bereits bei einem einfachen Transfer ohne Multisegmentierung.

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.

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

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

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?

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

Danke und Gruß -Wanninger

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