Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Deutsch
    24 Posts 4 Posters 4.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      l4k3k3m4n
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • W
        Wanninger
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            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

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • W
              Wanninger
              last edited by

              @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

              1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator
                last edited by

                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

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • W
                  Wanninger
                  last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • JeGrJ
                    JeGr LAYER 8 Moderator
                    last edited by

                    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

                    Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                    If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                    1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator
                      last edited by

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

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      1 Reply Last reply Reply Quote 0
                      • W
                        Wanninger
                        last edited by

                        …danke.

                        Hab's gestern schon gesehen, gleich probiert und es rennt wieder wie es soll.

                        -Wanninger

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.