Linux LACP-bonding: konfiguration, verifiering och felsökning

Linux LACP-bonding kombinerar flera Ethernet-gränssnitt till en enda logisk länk, vilket ger dig mer sammanlagd bandbredd och automatisk failover mellan fysiska nätverkskort. Det använder standarden IEEE 802.3ad, där båda sidor (server och switch) förhandlar om vilka länkar som är aktiva och hur trafiken ska fördelas. Det här inlägget behandlar vad LACP faktiskt gör, när man ska välja det framför andra Linux-bonding-lägen, hur man konfigurerar det på en modern Linux-server och hur man verifierar att det fungerar.

Vad är länkaggregering och LACP?

Länkaggregering kombinerar flera fysiska nätverksanslutningar till en logisk kanal. Det tjänar två syften: att öka den totala tillgängliga bandbredden över länkgruppen och att tillhandahålla automatisk failover om någon enskild länk går ner.

LACP, Link Aggregation Control Protocol, är den dynamiska versionen av länkaggregering som definieras av IEEE 802.3ad. Istället för att förlita sig på statisk konfiguration i båda ändarna utbyter LACP kontrollpaket som kallas LACPDU:er mellan servern och switchen. De två sidorna förhandlar om vilka länkar som ska ingå i aggregeringen, övervakar varje länks hälsa och tar in eller tar ut medlemmar ur gruppen när förhållandena förändras.

I en Linux-kontext körs LACP som läge 4 (802.3ad) i kärnans bonding-drivrutin. Drivrutinen skapar ett logiskt gränssnitt (vanligtvis bond0) som äger IP-adressen, medan fysiska gränssnitt som eth0 och eth1 blir underordnade bindningen. Ur operativsystemets perspektiv finns det ett nätverksgränssnitt. Ur nätverkets perspektiv finns det flera parallella Ethernet-länkar.

Några saker som LACP specifikt inte gör, men som folk ofta förväntar sig:

• En enskild TCP-anslutning går fortfarande över en fysisk länk. LACP balanserar flöden, inte paket inom ett flöde. Två bundna 1 GbE-länkar gör inte att en enskild nedladdning går snabbare än 1 Gbps.
• LACP kräver en switch som stöder 802.3ad. Det går inte att bilda en bond mot en ohanterad switch eller en switch som inte stöder LACP.
• Alla medlemslänkar måste köras med samma hastighet och duplex. Du kan inte binda en 1 GbE-port med en 10 GbE-port.

Linux-bondinglägen: när ska man använda LACP

Linux-bondingdrivrutinen stöder sju lägen. De flesta produktionsinstallationer använder ett av tre.

Läge 1: aktiv-backup

Ett gränssnitt är aktivt, de andra är inaktiva. Om det aktiva gränssnittet slutar fungera tar ett annat över inom några hundra millisekunder. Ingen switchkonfiguration behövs, vilket gör detta till det rätta valet när switcharna ligger utanför din kontroll eller inte stöder 802.3ad. Du får redundans men ingen extra bandbredd.

Läge 4: 802.3ad (LACP)

Alla medlemmar hanterar trafik. Bonding-drivrutinen och switchen använder LACP för att förhandla fram den aktiva uppsättningen och upptäcka fel. Utgående trafik balanseras mellan medlemmarna med hjälp av en hashpolicy som du konfigurerar. Detta är standardvalet för dedikerade servrar anslutna till hanterade switchar när du vill ha både redundans och extra bandbredd för arbetsbelastningar med flera flöden.

Läge 6: balance-alb

Adaptiv lastbalansering i båda riktningarna, utan krav på switchstöd. Drivrutinen fångar upp ARP-svar för att skriva om MAC-adresser och distribuera inkommande trafik. Det fungerar, men är mindre stabilt jämfört med LACP. Använd det endast när det är helt omöjligt att konfigurera switchsidan.

Beslutsregel:

• Ingen hanterad switch, eller om du endast behöver failover: läge 1 (active-backup).
• Hanterad switch, flera flöden, vill ha både bandbredd och redundans: läge 4 (LACP).
• Det går inte att använda en hanterad switch men du behöver balansering i båda riktningarna: läge 6 (balance-alb).

Lägena 0 (balance-rr), 2 (balance-xor), 3 (broadcast) och 5 (balance-tlb) finns, men är sällan det rätta valet på modern hårdvara. Välj läge 1 eller läge 4 om du inte har en specifik anledning att inte göra det.

Konfigurera LACP-bonding på Linux

På moderna Ubuntu- och Debian-system konfigureras LACP via netplan. På RHEL, CentOS Stream, AlmaLinux och Rocky Linux använder du NetworkManager via nmcli eller genom att redigera de underliggande anslutningsfilerna.

Netplan (Ubuntu, Debian)

Lägg in följande i /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Använd sedan netplan apply. De viktigaste parametrarna:

• mode: 802.3ad aktiverar LACP.
• lacp-rate: fast skickar LACPDU:er varje sekund istället för standardinställningen på 30 sekunder. Måste matcha switchinställningen.
• mii-monitor-interval: 100 kontrollerar länkstatus var 100:e millisekund.
• transmit-hash-policy: layer3+4 fördelar flöden efter käll-/mål-IP och TCP/UDP-port. Detta ger bättre balans än standard layer2 för typisk webb- och databastrafik.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Switch-sidan

Switchen behöver en LAG-grupp (ofta kallad port-channel) konfigurerad till LACP-aktivt läge, med samma antal medlemsportar som bonden. Den exakta syntaxen varierar beroende på leverantör, men kraven gör det inte: portarna måste vara i samma VLAN, inställda på samma hastighet och duplex, och använda LACP-aktivt läge på minst en sida. Att båda sidor är aktiva är den säkraste konfigurationen.

På Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

På Aruba/ProCurve:

trunk 1-2 trk1 lacp

Inställningen lacp_rate inställningen på switchen måste stämma överens med värden. En avvikelse här är ett av de vanligaste LACP-konfigurationsfelen och orsakar intermittent fladdring var 30:e sekund.

Verifiera och felsöka LACP

Kontrollera bondens live-status på Linux-sidan:

cat /proc/net/bonding/bond0

Fyra saker att leta efter i utdata:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation bekräftar att läge 4 är laddat.
2. Varje underordnat gränssnitt listas med MII Status: up och link failure count: 0.
3. Ett värde som inte är noll Partner Mac Address för varje underordnad. Om alla värden här är nollar betyder det att switchen inte skickar några LACP-paket alls, antingen för att porten inte ingår i en LACP-aktiv LAG eller för att kabeln är ansluten till fel port.
4. Aggregator ID är densamma på alla medlemmar. Olika ID:n betyder att medlemmarna inte är kombinerade, utan agerar oberoende av varandra.

Det snabbaste sättet att kontrollera att bandbredden används är att köra iperf3 med flera parallella strömmar (iperf3 -P 8) från en annan värd. Om den totala genomströmningen överstiger kapaciteten för en enskild länk, balanserar LACP korrekt. Ett test med en enda ström som visar hastigheten för en länk är förväntat beteende, inte ett fel.

De vanligaste LACP-problemen och deras orsaker:

• Partnerns MAC består av enbart nollor: switchporten ingår inte i en LACP-aktiv LAG, eller så är kablarna felkopplade.
• Bond startar men genomströmningen fastnar på en länk: hash-policyn är troligen inställd på layer2, som endast hashar på destinations-MAC. Byt till layer3+4.
• Intermittent fladdring var 30:e sekund: lacp_rate obestämdhet mellan värd och switch.
• En underordnad fungerar men den andra överför aldrig trafik: hastighet/duplex-mismatch, eller så ingår inte switchportarna i samma LAG-grupp på switchsidan.

När LACP inte är rätt lösning

LACP löser ett specifikt problem: att aggregera flera länkar mellan en värd och en switch (eller en switchstack) för att uppnå redundans och bandbredd per flöde. Det finns scenarier där det inte är rätt verktyg.

Om du bara behöver redundans och switcharna inte stöder 802.3ad, använd istället läge 1 (aktiv-backup). Det fungerar med allt.

Om du behöver koppla samman två separata switchar för redundans på chassinivå, kommer standard-LACP inte att spänna över två oberoende switchar. Du behöver Multi-Chassis Link Aggregation (MLAG), där två switchar presenterar sig som en enda logisk LACP-partner. De flesta leverantörer av företagsswitchar implementerar detta under sitt eget namn: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Om du behöver ett enda flöde som överskrider en länks bandbredd kan LACP inte göra detta. Alternativen är att använda en snabbare fysisk länk (ersätt 2x 10 GbE med 1x 25 GbE eller 1x 40 GbE) eller att använda en helt annan teknik. SR-IOV ger virtuella maskiner prestanda med nära linjehastighet för enstaka flöden genom att ge varje VM ett hårdvaruaccelererat virtuellt nätverkskort, men det löser ett annat problem och har sina egna begränsningar. Det är ett ämne för ett separat inlägg.

För de flesta dedikerade servrar och colocation-servrar som hanterar många samtidiga anslutningar är LACP fortfarande standardlösningen. Två bundna 10 GbE-länkar med layer3+4 hashing hanterar bekvämt över 18 Gbps sammanlagd trafik över många flöden samtidigt som de klarar ett nätverkskort- eller kabelhaveri utan att tappa ett paket.