Bonding Sieciowy Wyjaśniony: Wszystkie 7 Trybów, Architektura i Konfiguracja w Rzeczywistych Warunkach

Network bonding — zwany również NIC teaming, agregacją łączy lub Ethernet bonding — to technika łączenia dwóch lub więcej fizycznych kart sieciowych (NIC) w jeden logiczny interfejs zarządzany przez jądro systemu operacyjnego. Efektem jest zunifikowane urządzenie sieciowe zapewniające zwiększoną przepustowość zbiorczą, automatyczne przełączanie awaryjne i dystrybucję obciążenia na wszystkich łączach członkowskich jednocześnie.

Na poziomie jądra w systemach Linux, bonding jest implementowany przez moduł jądra `bonding`, który prezentuje pojedynczy wirtualny interfejs (zazwyczaj nazwany `bond0`) dla stosu sieciowego. Ta abstrakcja oznacza, że aplikacje, tablice routingu i reguły zapory sieciowej współpracują z jednym interfejsem niezależnie od liczby fizycznych kart NIC — kluczowy szczegół architektoniczny, który upraszcza zarządzanie przy jednoczesnym zapewnieniu odporności klasy korporacyjnej.

Dlaczego Network Bonding ma znaczenie w środowiskach produkcyjnych

Zanim przejdziemy do omawiania trybów, warto dokładnie zrozumieć, jaki problem rozwiązuje bonding — i gdzie nie ma zastosowania. Pojedynczy port Gigabit Ethernet ma twardy limit przepustowości wynoszący około 125 MB/s. W przypadku serwera baz danych, węzła pamięci masowej lub aplikacji internetowej o dużym ruchu ten limit jest szybko osiągany. Połączenie dwóch kart NIC 1 GbE nie podwaja magicznie przepustowości dla pojedynczego strumienia TCP (to powszechne nieporozumienie), ale pozwala wielu jednoczesnym przepływom nasycić oba łącza, efektywnie podwajając pojemność zbiorczą.

Poza surową przepustowością, bonding eliminuje pojedynczy punkt awarii, jakim jest samotna karta NIC lub kabel. W środowiskach, gdzie czas pracy mierzony jest w dziewiątkach, ma to ogromne znaczenie.

Główne korzyści w skrócie

• Zbiorcza przepustowość: Wiele fizycznych łączy przyczynia się do całkowitej przepustowości dla jednoczesnych przepływów ruchu
• Automatyczne przełączanie awaryjne: Wykrywanie awarii łącza (przez monitorowanie MII lub ARP) wyzwala przełączenie poniżej sekundy na działający interfejs
• Dystrybucja obciążenia: Ruch jest rozdzielany między interfejsy członkowskie zgodnie z aktywnym algorytmem bondingu
• Przezroczystość dla aplikacji: Interfejs bond ma jeden adres MAC i IP, nie wymagając żadnych zmian na poziomie aplikacji
• Efektywność kosztowa sprzętu: Łączenie kart NIC klasy commodity może być bardziej opłacalne niż modernizacja do pojedynczej karty 10 GbE w niektórych scenariuszach

Architektura Network Bonding: jak to działa pod maską

Sterownik bondingu jądra Linux działa pomiędzy Warstwą 2 (Łącza Danych) a fizycznymi sterownikami NIC. Gdy ramka jest transmitowana, polityka transmisji sterownika bondingu wybiera, który interfejs slave ma być użyty. Przy odbiorze wszystkie interfejsy slave przekazują ramki do mastera bond, który usuwa duplikaty i dostarcza je do stosu sieciowego.

Monitorowanie łącza to mechanizm wykrywający awarie. Istnieją dwie metody:

• Monitorowanie MII (Media Independent Interface): Odpytuje stan fizyczny każdej karty NIC w konfigurowalnym interwale (parametr `miimon`, zazwyczaj 100ms). Szybkie i niezawodne do wykrywania odłączenia kabla lub awarii NIC.
• Monitorowanie ARP: Wysyła żądania ARP do docelowego IP i obserwuje odpowiedzi. Bardziej przydatne, gdy trzeba zweryfikować łączność end-to-end, a nie tylko stan fizyczny łącza, ale wprowadza zależność od osiągalnego celu ARP.

Parametry `downdelay` i `updelay` dodają histerezę — zapobiegając szybkiemu przełączaniu, gdy łącze niestabilnie zmienia stan. Ustawienie ich na 200ms każdy jest powszechną bazą produkcyjną.

Wszystkie 7 trybów bondingu Linux: szczegółowe omówienie techniczne

Sterownik bondingu Linux definiuje siedem odrębnych trybów (od 0 do 6). Każdy implementuje inną politykę transmisji i zachowanie przy awarii. Wybór niewłaściwego trybu jest jedną z najczęstszych błędnych konfiguracji we wdrożeniach serwerów.

Tryb 0 — Round-Robin (balance-rr)

Pakiety są transmitowane sekwencyjnie przez wszystkie aktywne interfejsy slave w rotacji: pakiet 1 na eth0, pakiet 2 na eth1, pakiet 3 na eth0 i tak dalej.

Co faktycznie się dzieje: Round-robin działa na poziomie pakietów, nie przepływów. Oznacza to, że pojedyncze połączenie TCP może mieć pakiety dostarczone w złej kolejności, jeśli dwie ścieżki mają różne opóźnienia. Stos TCP hosta odbierającego zmieni ich kolejność, ale w praktyce powoduje to retransmisje i degradację przepustowości — szczególnie zauważalne przy dużych transferach plików przez pojedyncze połączenie.

Wymaganie przełącznika: Porty przełącznika muszą być skonfigurowane jako statyczna LAG (Link Aggregation Group) bez LACP. Bez tego przełącznik zobaczy ramki z tego samego adresu MAC przychodzące na wielu portach i może uruchomić wyłączenie ochrony przed pętlami.

Najlepsze zastosowanie: Obciążenia masowych transferów z wieloma jednoczesnym krótkotrwałymi połączeniami, gdzie zmiana kolejności pakietów jest tolerowana.

Tryb 1 — Active-Backup

Tylko jeden interfejs slave jest aktywny w danym momencie. Wszystkie pozostałe są w stanie gorącego rezerwy. Gdy aktywne łącze zawiedzie (wykryte przez monitorowanie MII lub ARP), sterownik bondingu promuje zapasowy slave i wysyła gratuitous ARP, aby zaktualizować tablice adresów MAC sieci.

Kluczowy niuans: W trybie active-backup interfejs bond zawsze prezentuje ten sam adres MAC sieci (MAC aktualnie aktywnego slave). Oznacza to, że nie jest potrzebna żadna specjalna konfiguracja przełącznika — z perspektywy przełącznika jest to normalne połączenie z pojedynczym hostem. Jest to jedyny tryb, który działa poprawnie na przełącznikach bez żadnej konfiguracji LAG.

Czas przełączania awaryjnego: Przy `miimon=100`, `downdelay=200`, `updelay=200` można oczekiwać przełączenia awaryjnego w około 200–300ms — wystarczająco szybko, aby uniknąć zerwania sesji TCP w większości przypadków.

Najlepsze zastosowanie: Scenariusze wysokiej dostępności, gdzie prostota i kompatybilność są ważniejsze niż przepustowość — interfejsy zarządzania, dostęp out-of-band lub dowolne środowisko, w którym przełącznik nie jest pod Twoją kontrolą.

Tryb 2 — Balance-XOR

Ruch jest dystrybuowany przy użyciu polityki haszowania transmisji stosowanej do każdego pakietu. Domyślny hash to `(source_MAC XOR destination_MAC) modulo slave_count`. Polityki wyższego poziomu (`layer3+4`) używają adresów IP i numerów portów dla lepszej dystrybucji.

Polityka layer3+4: Konfiguracja `xmit_hash_policy=layer3+4` znacznie poprawia dystrybucję poprzez haszowanie na podstawie źródłowego IP, docelowego IP, portu źródłowego i portu docelowego. Zapewnia to, że różne przepływy TCP do tego samego serwera docelowego są rozłożone na łącza, czego domyślny hash oparty na MAC nie może osiągnąć.

Wymaganie przełącznika: Statyczna konfiguracja LAG na przełączniku (tak samo jak Tryb 0), ale bez problemu zmiany kolejności pakietów, ponieważ wszystkie pakiety w ramach pojedynczego przepływu przechodzą przez ten sam interfejs.

Najlepsze zastosowanie: Środowiska wymagające równoważenia obciążenia bez obsługi LACP, szczególnie w połączeniu z polityką haszowania `layer3+4`.

Tryb 3 — Broadcast

Każdy pakiet jest transmitowany jednocześnie na wszystkich interfejsach slave. Każdy slave wysyła identyczną kopię każdej ramki.

Kiedy jest to faktycznie przydatne: Tryb broadcast nie dotyczy przepustowości — chodzi o gwarantowane dostarczenie do wielu segmentów sieciowych jednocześnie. Jest używany w wyspecjalizowanych scenariuszach klastrowania wysokiej dostępności, gdzie dwa oddzielne przełączniki lub ścieżki sieciowe muszą oba odbierać każdy pakiet (na przykład niektóre systemy replikacji pamięci masowej lub finansowe systemy transakcyjne z redundantnymi sieciami). Jest również używany w niektórych konfiguracjach monitorowania sieci.

Koszt przepustowości: Przy dwóch kartach NIC w trybie broadcast zużywasz 2x przepustowości w sieci dla każdego pakietu. Przy czterech kartach NIC — 4x. Ten tryb nigdy nie powinien być używany do ruchu ogólnego przeznaczenia.

Tryb 4 — 802.3ad / LACP (Dynamic Link Aggregation)

Jest to standard IEEE 802.3ad, implementowany przez Link Aggregation Control Protocol (LACP). Sterownik bondingu i przełącznik wymieniają PDU LACP (Protocol Data Units) w celu dynamicznego negocjowania, które łącza tworzą grupę agregacji, ich parametrów i stanu.

Jak działa negocjacja LACP: Każda strona wysyła LACPDU reklamujące swój priorytet systemu, priorytet portu i klucz agregacji. Łącza z pasującymi kluczami po obu stronach tworzą LAG. Jeśli łącze zawiedzie, LACP wykrywa to i usuwa je z grupy bez żadnej ręcznej interwencji.

Polityka haszowania transmisji: Podobnie jak Tryb 2, Tryb 4 używa polityki haszowania do dystrybucji obciążenia. Polityka `layer3+4` jest tutaj również zdecydowanie zalecana. Należy pamiętać, że LACP nie gwarantuje równoważenia obciążenia per pakiet — dystrybuuje przepływy między łącza, więc pojedynczy duży transfer pliku nadal będzie używał tylko jednego fizycznego łącza.

Konfiguracja przełącznika: Przełącznik musi mieć włączony LACP na odpowiednim kanale portów. Niezgodne tryby LACP (active vs. passive) są częstym źródłem awarii bondingu. Obie strony można ustawić na `active`, aby zapewnić, że negocjacja zawsze przebiega pomyślnie.

Najlepsze zastosowanie: Centra danych, serwery wysokiej wydajności i każde środowisko, w którym kontrolujesz konfigurację przełącznika. Jest to złoty standard dla produkcyjnego bondingu, gdy dostępna jest obsługa przełącznika.

Tryb 5 — Balance-TLB (Adaptive Transmit Load Balancing)

Tryb 5 dystrybuuje ruch wychodzący między wszystkie slave na podstawie aktualnego obciążenia każdego interfejsu (najmniej obciążony slave otrzymuje następny pakiet wychodzący). Ruch przychodzący jest odbierany tylko przez jeden wyznaczony slave.

Kluczowa zaleta: Nie jest wymagana żadna konfiguracja przełącznika. Interfejs bond używa różnych źródłowych adresów MAC per slave dla ruchu wychodzącego, co jest prawidłowym zachowaniem obsługiwanym transparentnie przez każdy przełącznik.

Ograniczenie: Ruch przychodzący nie jest równoważony. Jeśli Twój serwer głównie odbiera duże wolumeny danych (serwer pobierania, replika bazy danych odbierająca strumienie replikacji), Tryb 5 nie przynosi korzyści w tym kierunku. Jeśli Twój serwer głównie wysyła dane, Tryb 5 jest bardzo efektywny.

Zachowanie przy awarii: Jeśli slave odbierający zawiedzie, inny slave przejmuje rolę odbierania. Równoważenie obciążenia wychodzącego kontynuuje na pozostałych slave.

Tryb 6 — Balance-ALB (Adaptive Load Balancing)

Tryb 6 rozszerza Tryb 5 o równoważenie obciążenia przychodzącego przez negocjację ARP. Sterownik bondingu okresowo wysyła odpowiedzi ARP z różnymi źródłowymi adresami MAC do różnych klientów, powodując, że ci klienci wysyłają ruch zwrotny do różnych interfejsów slave.

Mechanizm manipulacji ARP: To jest sprytna część. Sterownik przechwytuje odpowiedzi ARP i rotuje źródłowy adres MAC między slave. Klienci buforują te wpisy ARP i kierują swój ruch do whichever slave MAC, którego się nauczyli. Osiąga to równoważenie obciążenia przychodzącego bez żadnej konfiguracji po stronie przełącznika.

Praktyczne zastrzeżenie: Równoważenie przychodzące oparte na ARP działa tylko dla hostów, które niedawno komunikowały się z serwerem z bondingiem. Nowe połączenia zawsze przychodzą na główny slave, dopóki nie zostanie wysłana odpowiedź ARP. W scenariuszach z dużą liczbą połączeń dystrybucja przychodzącego ruchu może być nierówna.

Najlepsze zastosowanie: Środowiska bez przełączników obsługujących LACP, które potrzebują dwukierunkowego równoważenia obciążenia. Solidny wybór dla środowisk VPS Hosting, gdzie wirtualny przełącznik hypervisora może nie obsługiwać LACP.

Tabela porównawcza trybów bondingu

Konfigurowanie Network Bonding w Linux

Wymagania wstępne

“`bash

Verify bonding module is available

modinfo bonding

Load the module if not already loaded

modprobe bonding

“`

Konfiguracja przez systemd-networkd (nowoczesne podejście)

Utwórz `/etc/systemd/network/bond0.netdev`:

“`ini

[NetDev]

Name=bond0

Kind=bond

[Bond]

Mode=802.3ad

TransmitHashPolicy=layer3+4

MIIMonitorSec=100ms

LACPTransmitRate=fast

“`

Utwórz `/etc/systemd/network/bond0.network`:

“`ini

[Match]

Name=bond0

[Network]

Address=192.168.1.10/24

Gateway=192.168.1.1

“`

Utwórz `/etc/systemd/network/eth0.network` i `eth1.network`:

“`ini

[Match]

Name=eth0

[Network]

Bond=bond0

“`

Konfiguracja przez `/etc/network/interfaces` (Debian/Ubuntu)

“`bash

auto bond0

iface bond0 inet static

address 192.168.1.10

netmask 255.255.255.0

gateway 192.168.1.1

bond-slaves eth0 eth1

bond-mode 4

bond-miimon 100

bond-lacp-rate 1

bond-xmit-hash-policy layer3+4

auto eth0

iface eth0 inet manual

bond-master bond0

auto eth1

iface eth1 inet manual

bond-master bond0

“`

Weryfikacja stanu bond

“`bash

Check bond status and slave states

cat /proc/net/bonding/bond0

Monitor interface statistics

ip -s link show bond0

Check LACP negotiation state (Mode 4)

cat /proc/net/bonding/bond0 | grep -A5 "LACP"

“`

Wynik `/proc/net/bonding/bond0` jest najważniejszym narzędziem diagnostycznym. Pokazuje aktywny slave, stan łącza każdego członka, status MII i (dla Trybu 4) informacje o partnerze LACP.

Network Bonding na serwerach dedykowanych i VPS

Na Serwerach Dedykowanych bare-metal masz pełną kontrolę zarówno nad konfiguracją NIC serwera, jak i (zazwyczaj) konfiguracją portów przełącznika, co sprawia, że Tryb 4 (LACP) jest naturalnym wyborem dla obciążeń produkcyjnych. Większość dostawców centrów danych może skonfigurować LACP na Twoich portach przełącznika na żądanie.

W środowiskach VPS z cPanel, warstwa wirtualnej sieci hypervisora obsługuje bazowy bonding na poziomie hosta. Gość VM zazwyczaj widzi pojedynczą wirtualną kartę NIC, ale host może działać na bondowanych fizycznych interfejsach pod spodem — zapewniając redundancję transparentnie.

Przy wdrażaniu obciążeń intensywnie wykorzystujących GPU na infrastrukturze GPU Hosting, network bonding staje się krytyczny dla wystarczająco szybkiego dostarczania danych do węzłów GPU, aby zapobiec głodzeniu I/O. Potoki treningowe i serwowanie inferencji czerpią korzyści ze zbiorczej przepustowości zapewnianej przez bonding LACP.

Typowe pułapki i przypadki brzegowe

Konflikty Spanning Tree Protocol (STP): Przy dodawaniu bondowanych portów do przełącznika, STP może tymczasowo blokować porty podczas negocjacji. Skonfiguruj PortFast (lub odpowiednik) na portach przełącznika, aby zapobiec 30-sekundowym opóźnieniom podczas zdarzeń link-up.

Niezgodności MTU: Wszystkie interfejsy slave w bond muszą mieć identyczne ustawienia MTU. Niezgodność powoduje sporadyczną utratę pakietów, która jest niezwykle trudna do zdiagnozowania. Zawsze weryfikuj za pomocą `ip link show` po konfiguracji.

Tryby timeout LACP: LACP obsługuje tryby timeout „slow” (30 sekund) i „fast” (1 sekunda). Zawsze używaj `lacp-rate fast` (`bond-lacp-rate 1`) w produkcji. Tryb slow oznacza, że uszkodzone łącze może być usunięte z LAG nawet po 90 sekundach.

Migracja na żywo maszyny wirtualnej: Jeśli VM z bondowanym interfejsem jest migrowana do innego hosta, adresy MAC bond mogą się zmienić w zależności od hypervisora. Może to powodować przestarzałe wpisy w pamięci podręcznej ARP i krótką utratę łączności. Przygotuj gratuitous ARP w skryptach migracji.

Asymetryczne haszowanie: W Trybie 4 z haszowaniem `layer3+4`, ruch z serwera A do serwera B może przechodzić przez eth0, podczas gdy ruch zwrotny z B do A przechodzi przez eth1 na bond B. Jest to normalne i oczekiwane — każdy punkt końcowy niezależnie haszuje swój ruch wychodzący.

Ingerencja NetworkManager: W systemach RHEL/CentOS, NetworkManager może ingerować w ręcznie skonfigurowane bondy. Albo skonfiguruj bondy przez interfejs nmcli NetworkManager, albo wyłącz NetworkManager dla odpowiednich interfejsów używając `NM_CONTROLLED=no` w pliku konfiguracyjnym interfejsu.

Bonding a inne techniki sieci wysokiej dostępności

Network bonding nie jest jedynym podejściem do redundancji NIC. Równie ważne jest zrozumienie, kiedy używać alternatyw.

MLAG (Multi-Chassis Link Aggregation) zasługuje na szczególną wzmiankę: pozwala serwerowi działającemu w Trybie 4 bondingu podłączyć dwie karty NIC do dwóch fizycznie oddzielnych przełączników, oba uczestniczące w tej samej logicznej LAG. Eliminuje to sam przełącznik jako pojedynczy punkt awarii — poziom redundancji, którego standardowy LACP z pojedynczym przełącznikiem nie może zapewnić.

Macierz decyzyjna: wybór właściwego trybu bondingu

Użyj tego schematu, aby wybrać tryb bondingu:

Czy kontrolujesz konfigurację przełącznika?

• Nie → Przejdź do Trybu 1, 5 lub 6
• Potrzebujesz dwukierunkowego równoważenia obciążenia? → Tryb 6
• Głównie ruch wychodzący? → Tryb 5
• Czyste przełączanie awaryjne, maksymalna prostota? → Tryb 1
• Tak → Przejdź do Trybu 0, 2 lub 4
• Potrzebujesz dynamicznej negocjacji i zgodności z najlepszymi praktykami? → Tryb 4 (LACP)
• Statyczna LAG, prostsze ustawienie? → Tryb 2 z hashem layer3+4
• Wyspecjalizowane wymaganie broadcast? → Tryb 3

Czy to interfejs zarządzania/IPMI? Zawsze używaj Trybu 1. Nigdy nie ryzykuj interfejsu zarządzania w trybie wymagającym konfiguracji przełącznika.

Czy jesteś na platformie chmurowej lub wirtualnej? Sprawdź, czy wirtualny przełącznik hypervisora obsługuje LACP. Jeśli nie, Tryb 6 zapewnia najlepszą równowagę między dystrybucją obciążenia a kompatybilnością.

Dla zespołów zarządzających wieloma serwerami przez Panele Sterowania VPS, weryfikacja stanu bondingu powinna być częścią standardowej listy kontrolnej po wdrożeniu, obok weryfikacji SSL przez Certyfikaty SSL i sprawdzania propagacji DNS po Rejestracji Domeny.

Techniczna lista kontrolna kluczowych wniosków

• Zawsze ustawiaj `miimon=100` i `downdelay=200 updelay=200` jako bazę dla monitorowania MII w produkcji
• Używaj `xmit_hash_policy=layer3+4` z Trybem 2 i Trybem 4, aby zapewnić dystrybucję na poziomie przepływu, a nie na poziomie MAC
• Weryfikuj `/proc/net/bonding/bond0` natychmiast po konfiguracji — nie zakładaj, że działa
• Skonfiguruj szybkość LACP na `fast` w Trybie 4, aby skrócić czas wykrywania awarii z 90 sekund do 3 sekund
• Upewnij się, że wszystkie slave NIC mają identyczne ustawienia MTU, prędkości i dupleksu przed dodaniem ich do bond
• Na produkcyjnych Serwerach Dedykowanych zawsze żądaj konfiguracji LACP od dostawcy centrum danych zamiast używać statycznej LAG
• Testuj przełączanie awaryjne jawnie przez odłączenie jednego kabla — nie zakładaj, że konfiguracja jest poprawna, dopóki nie zweryfikujesz jej w warunkach awarii
• Dokumentuj, która fizyczna karta NIC odpowiada któremu slave (eth0, eth1) używając `ethtool -i eth0`, aby uniknąć pomyłek podczas fizycznej konserwacji
• Dla redundancji między przełącznikami w krytycznych środowiskach, zbadaj MLAG przed wyborem LACP z pojedynczym przełącznikiem

FAQ

Czy network bonding podwaja prędkość pojedynczego pobierania pliku?

Nie. Bonding dystrybuuje ruch między łącza na poziomie przepływu (lub pakietu w Trybie 0). Pojedyncze połączenie TCP używa tylko jednego fizycznego łącza w danym momencie w większości trybów. Bonding zwiększa zbiorczą przepustowość dla wielu jednoczesnych połączeń, a nie prędkość pojedynczego połączenia.

Jaka jest różnica między bondingiem Trybu 4 (LACP) a statyczną LAG?

Statyczna LAG (używana przez Tryby 0 i 2) ręcznie definiuje, które porty tworzą grupę agregacji bez żadnej negocjacji. LACP (Tryb 4) dynamicznie negocjuje LAG używając pakietów kontrolnych, automatycznie wykrywając błędne konfiguracje, uszkodzone łącza oraz dodając/usuwając członków. LACP jest bardziej niezawodny i jest standardem branżowym dla wdrożeń produkcyjnych.

Czy mogę skonfigurować network bonding na VPS?

To zależy od hypervisora i dostawcy hostingu. Większość instancji VPS w chmurze prezentuje gościowi pojedynczą wirtualną kartę NIC, z bondingiem obsługiwanym na poziomie hypervisora. Niektórzy dostawcy oferujący VPS podobne do bare-metal lub dedykowane instancje chmurowe obsługują bonding na poziomie gościa. Sprawdź u swojego dostawcy przed próbą konfiguracji bondingu wewnątrz gościa VPS.

Co dzieje się z aktywnymi połączeniami, gdy bondowane łącze zawiedzie?

W Trybie 1 (Active-Backup), bond wysyła gratuitous ARP po przełączeniu awaryjnym, aktualizując tablice MAC przełącznika. Istniejące połączenia TCP doświadczają krótkiej przerwy (zazwyczaj poniżej 300ms przy szybkim monitorowaniu MII), ale generalnie przeżywają. W Trybie 4, LACP wykrywa awarię i redystrybuuje przepływy do działających łączy — istniejące przepływy na uszkodzonym łączu będą musiały zostać ponownie nawiązane przez aplikację.

Dlaczego mój bond Trybu 4 pokazuje tylko jeden aktywny slave w `/proc/net/bonding/bond0`?

Najczęstszą przyczyną jest błędna konfiguracja po stronie przełącznika. Sprawdź, czy porty przełącznika są skonfigurowane w tym samym kanale portów z włączonym LACP w trybie active. Sprawdź również, czy `lacp-rate` jest ustawiony spójnie po obu stronach. Niezgodny klucz LACP lub priorytet systemu może uniemożliwić agregację nawet gdy fizyczne łącza są aktywne.