LACP och link aggregation hemma – när hjälper det egentligen?

Du har precis uppgraderat din switch till en modell med LACP-stöd, slagit ihop två 1 GbE-portar mot din NAS och förväntar dig 2 Gbit/s. Men när du kopierar en stor fil från din dator står mätaren envist kvar på 113 MB/s – exakt samma som med en enda kabel. Har du gjort något fel? Förmodligen inte. Du har bara råkat ut för link aggregation-fällan som fångar nästan alla hemlabbsbyggare första gången.

LACP – Link Aggregation Control Protocol – är ett utmärkt verktyg, men det gör inte det som många tror att det gör. Det ökar inte hastigheten för en enskild anslutning. Det ökar den totala kapaciteten för många samtidiga anslutningar. Skillnaden är avgörande för om tekniken är värd besväret hemma hos dig eller om du bara lagt till komplexitet utan nytta.

Vad LACP faktiskt gör

LACP (standardiserat som IEEE 802.3ad, numera 802.1AX) låter flera fysiska Ethernet-länkar mellan två enheter fungera som en enda logisk länk. Protokollet förhandlar fram vilka portar som ingår och övervakar dem: om en kabel dras ur flyttas trafiken automatiskt över till de kvarvarande länkarna. Det ger både högre samlad kapacitet och redundans.

Den kritiska detaljen är hur trafiken fördelas. Switchen skickar inte paket växelvis över länkarna som man kanske föreställer sig. I stället beräknar den ett hashvärde för varje flöde – typiskt baserat på käll- och destinations-MAC, IP-adresser och portnummer – och varje flöde låses till en av de fysiska länkarna. Det garanterar att paket inom samma anslutning kommer fram i rätt ordning, vilket TCP kräver.

Konsekvensen är brutal i sin enkelhet: en enskild TCP-anslutning – som din filkopiering – hamnar alltid på en enda fysisk länk. Två aggregerade 1 GbE-länkar ger dig 2 Gbit/s totalt, men varje enskilt flöde är fortfarande begränsat till 1 Gbit/s. Först när du har flera samtidiga flöden till olika klienter börjar den andra länken bidra.

LACP eller statisk aggregering?

Det finns två sätt att slå ihop länkar: dynamiskt med LACP eller statiskt konfigurerat. Med LACP utbyter båda sidorna kontrollpaket (LACPDU:er) och kommer överens om vilka länkar som ingår; felaktiga eller felkopplade kablar upptäcks och exkluderas automatiskt. Med statisk aggregering tvingar du bara ihop portarna utan förhandling.

För hemmabruk är rekommendationen tydlig: använd LACP när båda sidorna stöder det. Det är mer förlåtande mot misstag – kopplar du fel kabel eller har en trasig port vägrar gruppen att bildas i stället för att tyst skicka trafik ut i tomma intet. Statisk aggregering har sin plats mot enheter som saknar LACP-stöd, men då får du själv ansvara för att konfigurationen är identisk på båda sidorna.

Vad du behöver: switch, NIC:ar och kablar

För att LACP ska fungera hemma behöver du tre saker: en switch med stöd för 802.3ad/802.1AX, en NAS eller server med minst två nätverksportar, och ett operativsystem som kan skapa en bond. De flesta managed switchar har LACP-stöd, men kontrollera specifikationerna: de allra billigaste ”smart managed”-modellerna saknar det ibland.

Konfiguration på NAS:en

I TrueNAS skapar du en link aggregation under nätverksinställningarna och väljer LACP som protokoll. I Linux gör du samma sak med nätverksverktygen eller netplan/NetworkManager beroende på distribution. Viktigt: båda NIC:arna måste vara anslutna till samma switch, och switchportarna måste vara konfigurerade för LACP – annars får du antingen ingen anslutning alls eller, värre, en loop som sänker hela nätverket.

Hash-policyn avgör allt

Både switchen och servern har en inställning för hur flöden hashas över länkarna. Vanliga lägen är Layer 2 (MAC-adresser), Layer 2+3 (MAC + IP) och Layer 3+4 (IP + portnummer). För en NAS som pratar med många olika klienter ger Layer 3+4 bäst spridning, eftersom varje klientanslutning då sannolikt hamnar på olika länkar.

Hash-policyns fälla – därför ser du ingen skillnad

Låt oss återvända till besvikelsen i inledningen. Du kopierar en fil från din dator till NAS:en över en LACP-grupp med två länkar, och hastigheten är oförändrad. Det är förväntat beteende: din kopiering är ett enda TCP-flöde, hashen låser det till en länk, och den länken gör 1 Gbit/s precis som förut.

Fällan blir ännu tydligare i ett vanligt hushåll. En mediaserver som strömmar film till TV:n, en dator som tar backup och en telefon som synkar foton – det är tre flöden, men om två av dem hashas till samma länk får du ändå ingen jämn fördelning. Hashningen är deterministisk, inte lastbalanserande: den bryr sig inte om hur belastad en länk är, bara om vilket hashvärde flödet får.

Med få flöden är ojämn fördelning snarare regel än undantag. Det finns visserligen ett undantag: SMB Multichannel öppnar flera parallella TCP-anslutningar med olika portnummer, och med Layer 3+4-hashning kan dessa hamna på olika fysiska länkar. Men notera ironin: det är Multichannel som gör jobbet – LACP:et ensamt hade inte räckt.

När är det värt det i hemlabbet?

LACP är rätt verktyg när du har många samtidiga klienter mot en central resurs. Ett konkret hemmalabbsscenario: en Proxmox- eller TrueNAS-maskin som samtidigt servar flera VM:ar, containrar, en mediaserver och två-tre datorer som säkerhetskopierar. Där ger aggregeringen både högre total kapacitet och välkommen redundans – en kabel kan gå sönder mitt i natten utan att tjänsterna märker något.

LACP är fel verktyg när ditt mål är att en enskild dator ska få snabbare överföringar. Då är en enda snabbare länk nästan alltid bättre: ett begagnat 10 GbE-nätverkskort och en direktkabel till NAS:en (eller en billig 2,5 GbE-switch) ger dig verklig, mätbar hastighet för varje enskild överföring – utan hash-policyer att fundera över.

Räkna också med komplexiteten. En LACP-grupp är ytterligare en sak som kan gå fel vid omstarter, firmware-uppdateringar och switchbyten. I ett hemlabb där du är både administratör och användare har enkelhet ett värde i sig. Om du inte har ett tydligt flerklientbehov är rådet enkelt: lägg pengarna på snabbare länkar i stället för fler länkar.

Viktiga punkter

  • LACP slår ihop flera fysiska länkar till en logisk länk med högre total kapacitet och inbyggd redundans.
  • Ett enskilt TCP-flöde låses alltid till en fysisk länk via hashning – en filkopiering blir aldrig snabbare av LACP.
  • Använd dynamisk LACP (802.3ad/802.1AX) framför statisk aggregering; det upptäcker felkopplingar automatiskt.
  • Välj hash-policy Layer 3+4 för bästa spridning när många klienter pratar med din NAS.
  • LACP lönar sig vid många samtidiga klienter mot en server; för en enskild snabb klient är en snabbare länk (2,5/10 GbE) bättre.
  • SMB Multichannel kan i kombination med LACP utnyttja flera länkar även för en klient – men då är det Multichannel som gör jobbet.
Alternativ Enskilt flöde Total kapacitet Redundans Komplexitet
Enkel 1 GbE-länk 1 Gbit/s 1 Gbit/s Nej Låg
LACP 2 × 1 GbE 1 Gbit/s 2 Gbit/s Ja Medel
LACP 4 × 1 GbE 1 Gbit/s 4 Gbit/s Ja Medel–hög
Enkel 2,5 GbE-länk 2,5 Gbit/s 2,5 Gbit/s Nej Låg
Enkel 10 GbE-länk 10 Gbit/s 10 Gbit/s Nej Låg

Slutsats

LACP är ett moget och pålitligt protokoll – men det löser ett flerklientproblem, inte ett hastighetsproblem. Servar din NAS många enheter samtidigt och vill du ha redundans mot kabelbrott? Kör LACP med Layer 3+4-hashning och sov gott. Vill du att din egen dator ska kopiera snabbare? Köp ett 2,5 eller 10 GbE-kort i stället – billigare, enklare och med en hastighetsökning du faktiskt kan mäta.

Leave a Comment