LAGG aus einem vorhandenen Interface bilden

mrsunfire

Hallo,

ich habe aktuell für das LAN Interface einen Downlink und möchte diesen nun mit einem zweiten Port aggregieren (inkl. aller Nachteile...). Ist dies möglich? Aktuell sehe ich nur die Chance zwei ungenutzte Ports zu aggregieren und nicht einen bereits konfigurierten Port einen weiteren hinzuzufügen als LAGG.

viragomann

@mrsunfire
Hallo,

Aktuell sehe ich nur die Chance zwei ungenutzte Ports zu aggregieren

Das heißt, du müsstest den aktuellen LAN Port vorübergehend frei machen.
Einfach das LAN in Interfaces > Assignments auf einen anderen Port legen.
Zuvor musst du aber sicherstellen, dass du über ein anderes Interface Zugriff auf die pfSense hast, wenn du keinen freien Netzwerkport, an dem du deinen Rechner anschließen kannst, bspw. WAN od. VPN.

JeGr

@mrsunfire Doch kann man machen. Wenn du ein LAGG bilden willst egal welcher Art, dann muss primär erstmal dein Switch mitspielen. Ob das Failover, LACP o.ä. ist bestimmen beide Seiten. Wenn klar ist, was konfiguriert werden muss:

den neuen 2. Port nehmen und alleine in ein lagg packen
auf dem Switch ebenfalls einrichten
LAGG mit LACP und nur einem Port ist eigentlich unspektakulär und sollte OOTB funktionieren.
jetziges Interface (LAN) von HW Port xy<n> auf lagg0 umstellen
Testen ob dein LAN noch geht
wenns läuft, den alten physikalischen Port
auf zweiter Port dem Lagg hinzufügen (am besten auf dem Switch noch nicht konfiguriert, dann sollte der eigentlich als "nicht erkannt/genutzt/down" einfach rumidlen im LAGG Status)
auf Switch den zweiten Port mit in die LACP Konfig rein
Switch und Sense sollten (bei LACP) die Aushandlung hinbekommen dass jetzt 2 NICs active/collecting sind

Das geht eigentlich auch ohne sich damit auszusperren. Sinnvoll ist dann natürlich, wenn man Konsolen-Zugriff hat auf einem anderen IF oder per serial console, damit man notfalls einen Schritt zurück gehen kann (rollback config auf letzte/vorletzte etc.)

Cheers

thundergate

@mrsunfire said in LAGG aus einem vorhandenen Interface bilden:

mit einem zweiten Port aggregieren (inkl. aller Nachteile...)

Was wären denn die "Nachteile" eines LAGGs? Ist das noch nicht ausgereift oder fehlerbehaftet, oder was meinst Du mit Nachteilen?

JeGr

@thundergate

nochmals abstrakte Softwareschicht "on top" des Interface, damit ggf. schwerer/schwieriger zu debuggen
mehr Fehlerpotential bei der Konfiguration - wenn am Switch bspw. der Port um-/falsch konfiguriert wird, gibt es im besten Fall einen kurzen Schluckauf im Netz weil sich das Port-Bündel auftrennt. Im schlechtesten Fall können sich die Ports nicht mehr aushandeln und gehen down
wenn darüber alle internen Netze inkl. Management gehen, kann man sich im unglücklichen Falle aussperren
1+1 != 2 -> LAGGs mit bspw. LACP bündeln nicht einfach die Geschwindigkeit, sondern nutzen Source/Destination/etc. Hash Tabellen um die Verbindungen über je eine Leitung zu schicken. Einzelne Clients können das oftmals nicht ausnutzen und bekommen davon nichts zu sehen.

LAGG wird durch das Wort "aggregation" gern als "Kanalbündelung" gesehen und daher wird manchmal davon ausgegangen, dass man bei solchen Setups dann auch direkt mehr Performance sehen kann. Das ist aber wie oben beschrieben nicht der Fall, es geht hier lediglich bei Last von mehreren Clients um bessere Lastverteilung und Performance in Summe, nicht für einzelne Clients. Bei 10 Clients die bspw. alle einen Server nutzen, der mittels LACP m Switch hängt, wird das gut sichtbar.

Aber:

Server (1x10G) <###> (1x10G) pfSense (2x1G) <===> (2x1G)  Switch (1x2.5G) <---> LAN Client mit 2.5G

bei einem Beispiel wie hier (Server mit 10G angebunden, Client mit 2.5G aber die Sense dazwischen kann nur 10/1G, daher mit LAGG an Switch mit 2G uplinked) profitiert aber der Client nicht (oder nicht ohne speziellen Client) von mehr Durchsatz durch das Linkbündel.

Daher das 1+1!=2 in diesem Fall und da das nicht gilt, ist oftmals der Overhead durch LAGG/LACP, Konfigurationsaufwand und problematischere Debugging eher ein Grund es zu lassen.

Cheers

thundergate

@jegr Danke für die ausführliche Antwort.

Bei mir wäre es wenn ich es richtig verstanden habe, doch gar nicht so unsinnig es einzusetzen.

pfSense hat 4 x 2.5G Ports.
Switch hat nur 1G Port
Mein Proxmox Server hat 2.5G Port

Wollte den eigentlich direkt an einen der Ports der pfSense hängen, aber dann müsste ich bridgen, was ja auch wiederum Probleme und "Dinge" mit sich bringt.

Mein Plan war eigentlich den Switch an einem Port der pfSense zu betreiben mit div. VLANs usw.
Den Proxmox am anderen Port ebenfalls in dem gleichen Netz wie der Switch, da auf der Proxmox Maschine ja der UniFi-Controller laufen soll (u.a.).

Aber das geht ja nur, wenn man die zwei Netzwerk-Ports bridged.

Jetzt ist die Frage, was in der Konstellation sinniger ist?! Auf dem Proxmox soll auch irgendwann noch ne Nextcloud oder OMV laufen.

NOCling

Ich habe igc0 extra frei gelassen, denn ist die Software mal hin, dann komme ich nach dem Recovery über dieses vom Laptop direkt dran und kann die Konfiguration wieder hoch laden.
Ist das ein LAG, stehst erstmal doof da.
Da meine Switch in einem Management Netz sind, könnte ich dann zwar mit Console dran, aber so stecke ich einfach das Kabel in den Laptop und kann die 61er sicher neu betanken.

JeGr

@thundergate said in LAGG aus einem vorhandenen Interface bilden:

Wollte den eigentlich direkt an einen der Ports der pfSense hängen, aber dann müsste ich bridgen, was ja auch wiederum Probleme und "Dinge" mit sich bringt.

Müsste man sich in der neuen Version 23.01/2.7 mal ansehen, das Bridging im Stack ist in FBSD13/14 wesentlich besser geworden. Könnte sein, dass sich das dann durchaus rentiert, das einfach direkt anzuschließen, wenn man schon Geräte mit 2.5 hat.

Aber warum glaubst du denn dass das sinnvoll wäre für dich? Bist du mit so viel "power" Unterwegs, dass du allen ernstes 125MB/s vom Gigabit auf Dauer ausmaxen kannst und mehr brauchst? Für wie viele Clients? Nur wegen Nextcloud und OMV?