Коли LACP-бонд флапає, це не відбувається голосно. Це відбувається як комітет: періодично, з оправданою заперечуваністю і завжди під час найвищого навантаження. Одна хвилина — здорова зв’язка 2×25G; наступна — трафік схоплений на одному лінку, TCP робить ретрансляції, а в чаті з’являється улюблена фраза: «Мушу бути мережа».
Це польовий посібник для операторів Debian 13, яким треба не просто усувати несправність, а довести її. Довести, чи хост поводиться неправильно, чи комутатор неправильно налаштований, чи фізичний рівень підкидає вам інтерпретативний танець.
Швидкий план діагностики
Якщо у вас є лише 15 хвилин до пропозиції перезавантажити ядро мережі, зробіть це у такому порядку. Мета — відокремити «проблему переговорів LACP» від «проблеми carrier/PHY» від «хостової мережевої стекової дивності».
1) Підтвердіть: це flapping carrier чи flapping стану LACP
Carrier down/up вказує на оптику/кабелі/ASIC/драйвер/прошивку. Зміни стану LACP при стабільному carrier вказують на розбіжність конфігурації, таймери, проблеми MLAG/стека або втрату LACPDU.
cr0x@server:~$ ip -br link show
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eno1 UP 3c:fd:fe:aa:bb:01 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
eno2 UP 3c:fd:fe:aa:bb:02 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
bond0 UP 3c:fd:fe:aa:bb:ff <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
Що це означає: Якщо один зі slave показує DOWN або не має LOWER_UP під час флапу, ви шукаєте фізику/драйвер. Якщо slave залишаються UP, але bond0 втрачає активних учасників, причиною є переговори LACP або доставка LACPDU.
Рішення: Якщо carrier падає, переходьте до лічильників ethtool і перевірки фізичного рівня. Якщо carrier стабільний — концентруйтеся на LACPDU, таймерах і консистентності комутатора.
2) Витягніть стан драйвера bonding і індикатори «останнього крушіння»
cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.1.0
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 51
Partner Mac Address: 00:11:22:33:44:55
Slave Interface: eno1
MII Status: up
Speed: 25000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 3c:fd:fe:aa:bb:01
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 3
Partner Churned Count: 3
details actor lacp pdu:
system priority: 65535
system mac address: 3c:fd:fe:aa:bb:ff
port key: 17
port priority: 255
port number: 1
details partner lacp pdu:
system priority: 32768
system mac address: 00:11:22:33:44:55
oper key: 51
port priority: 128
port number: 49
Slave Interface: eno2
MII Status: up
Speed: 25000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 3c:fd:fe:aa:bb:02
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 3
Partner Churned Count: 3
Що це означає: «Churned» і зростаючі лічильники churn — ваша димова сигара щодо нестабільності переговорів LACP або втрат LACPDU. Зростання Link Failure Count більше вказує на фізичну/драйверну проблему. Partner MAC, ключі і номера портів — це ідентифікація іншого боку так, як її бачить хост.
Рішення: Якщо лічильники churn ростуть при стабільному MII, вимагайте логів LACP з боку комутатора і перевірте доставку LACPDU за допомогою захоплення трафіку.
3) Перевірте журнали ядра на предмет скидів NIC, проблем PCIe або подій carrier
cr0x@server:~$ journalctl -k -S -30min | egrep -i 'bond0|eno1|eno2|lacp|link up|link down|reset|timeout|tx hang|firmware'
[...]
kernel: bond0: (slave eno1): Enslaving as an active interface with a down link.
kernel: eno1: Link is Down
kernel: eno1: Link is Up - 25Gbps/Full - flow control rx/tx
kernel: bond0: (slave eno1): link status definitely up, 25000 Mbps full duplex
kernel: bond0: (slave eno1): Actor Churn State is churned
Що це означає: Ядро легко видасть причину. «Link is Down/Up» = carrier. «TX hang/reset/firmware» = проблема на боці хоста. Churn без link down вказує на розбіжність LACP або втрату LACPDU.
Рішення: Якщо ви бачите resets/timeouts — перестаньте сперечатися про конфігурацію комутатора і почніть дивитися драйвер/прошивку та здоров’я PCIe.
4) Отримайте лічильники помилок на slave NIC
cr0x@server:~$ ethtool -S eno1 | egrep -i 'err|drop|crc|fcs|miss|timeout|reset|align|symbol|disc|over'
rx_crc_errors: 0
rx_fcs_errors: 0
rx_missed_errors: 0
rx_discards: 12
tx_errors: 0
tx_timeout_count: 0
Що це означає: CRC/FCS/symbol помилки явно вказують на фізичну проблему (оптика, кабель, брудне волокно, граничний DAC). Discards можуть бути через затори, кільцеві буфери або поведінку комутатора.
Рішення: Якщо CRC/FCS зростають під час флапів — вважайте фізичний шлях підозрілим, поки не доведено протилежне.
5) Якщо неясно — захопіть LACPDU протягом 60 секунд під час проблеми
Про це більше далі, але це найшвидший спосіб показати «хост відправив LACPDU; комутатор не відповів» (або навпаки).
Що насправді означає «флапи LACP»
У Linux bonding mode 802.3ad «флапи» зазвичай означають, що зв’язка багаторазово змінює, які slave-інтерфейси є collecting/distributing. Це може відбуватися при фізично стабільних лінках. Також це може статися через фактичні падіння фізичних лінків, у такому випадку LACP — лише посланець, якого підстрелили.
Операційно ви побачите:
- Один slave багаторазово видаляється/додається до активного агрегатора.
- Partner MAC або Partner Key змінюються несподівано (часто через MLAG/проблеми стека).
- Пропускна здатність зі «зубцями», спайки затримки зберігання, TCP ретрансміси та питання «чому половина пропускної здатності зникла?»
LACP має таймери. LACP має автомати станів. LACP також любить виявляти усі невідповідності, про які ви не підозрювали. Трюк — збирати докази, що переживуть міжкомандні суперечки: логи, лічильники і кадри на лінії.
Цікаві факти та контекст (коротко, конкретно)
- LACP стандартизовано як IEEE 802.1AX; старі документи і багато інструментів все ще посилаються на IEEE 802.3ad, який був включений до 802.1AX.
- «Fast» LACP rate ≈ 1 секунда між LACPDU; «slow» ≈ 30 секунд. «Fast» швидше виявляє проблеми — і швидше посилює проблеми з втратою пакетів.
- Linux bonding передує сучасній культурі «мережевий стек як код»; /proc/net/bonding залишається одним із найкорисніших діагностичних файлів у системі.
- Багато комутаторів трактують LACP як контрольний трафік з іншими правилами чергування ніж дані; затори або полісінг можуть скидати LACPDU, тоді як дані «працюють здебільшого».
- Реалізації MLAG різняться; деякі обробляють ідентичність партнера і ключування так, що плутають хости під час переходів, якщо конфігурація не ідентична.
- Політика хешування трансляції важить більше, ніж визнають; «layer2» може фіксувати потоки дивно в віртуалізованих середовищах, а «layer3+4» може ламати очікування при NAT або асиметричному маршрутуванні.
- Агрегація лінків не сумує пропускну здатність для одного TCP-потоку, якщо ви не робите щось спеціальне; більшість розгортань покладаються на хешування на потік.
- Carrier up не гарантує чистого фізичного рівня; можна мати стабільний лінк з періодичними CRC, що викликають вищележний churn і ретрансміси.
- Деякі NIC offload історично погано взаємодіяли з bonding (особливо VLAN offload і деякі версії драйверів); режим відмови виглядає як «мережа ненадійна».
Докази зі сторони хоста: перевірки Debian 13, що витримають постмортем
Debian 13 дає сучасне ядро, systemd і звичний набір інструментів Linux. Використовуйте їх, як формуєте матеріал справи, а не як граєте в whack-a-mole.
Завдання 1: Визначте, хто конфігурує bонд (systemd-networkd vs ifupdown)
cr0x@server:~$ systemctl is-active systemd-networkd
inactive
cr0x@server:~$ dpkg -l | egrep 'ifupdown|network-manager|systemd-networkd'
ii ifupdown 0.8.41 amd64 high level tools to configure network interfaces
Що це означає: Потрібно знати площину управління. Якщо два менеджери конфліктують — ви отримаєте «флапи», що насправді є подіями переконфігурації.
Рішення: Якщо більше одного активного — оберіть один і відключіть решту перед подальшими діями. Відлагоджувати рухому ціль — хобі, не SRE-практика.
Завдання 2: Показати поточну конфігурацію бонду з точки зору ядра
cr0x@server:~$ grep -H . /sys/class/net/bond0/bonding/*
/sys/class/net/bond0/bonding/mode: 802.3ad 4
/sys/class/net/bond0/bonding/lacp_rate: 1
/sys/class/net/bond0/bonding/miimon: 100
/sys/class/net/bond0/bonding/xmit_hash_policy: layer3+4 1
/sys/class/net/bond0/bonding/ad_select: stable 1
/sys/class/net/bond0/bonding/min_links: 1
Що це означає: Це правда, яку застосовує ядро, а не те, що каже ваш конфіг-файл. lacp_rate «1» = fast.
Рішення: Якщо miimon = 0 і ви покладаєтесь на сповіщення драйвера про лінк — ви довіряєте драйверу. Це може бути нормально, але принаймні будьте явними.
Завдання 3: Перевірте slave-інтерфейси і помилки зі VLAN на slave vs VLAN на bond
cr0x@server:~$ ip -d link show bond0
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:aa:bb:ff brd ff:ff:ff:ff:ff:ff
bond mode 802.3ad miimon 100 updelay 0 downdelay 0 lacp_rate 1 ad_select stable xmit_hash_policy layer3+4
cr0x@server:~$ ip -br link show master bond0
eno1 UP 3c:fd:fe:aa:bb:01 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
eno2 UP 3c:fd:fe:aa:bb:02 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
Що це означає: Бажано мати VLAN поверх bond0, а не на окремих slave (якщо тільки у вас немає спеціального дизайну і відповідної конфігурації комутатора). «ip -d» показує параметри бонду і MTU.
Рішення: Якщо MTU відрізняється між slave або комутатором — ви можете не бачити «флапів», але помітите симптоми, схожі на них. Узгодьте MTU раніше.
Завдання 4: Слідкуйте за станом бонду в реальному часі під час флапу
cr0x@server:~$ watch -n 1 'grep -E "MII Status|Slave Interface|Aggregator ID|Churn|Link Failure" -n /proc/net/bonding/bond0'
Every 1.0s: grep -E "MII Status|Slave Interface|Aggregator ID|Churn|Link Failure" -n /proc/net/bonding/bond0
5:MII Status: up
18:Active Aggregator Info:
19: Aggregator ID: 1
20: Number of ports: 2
34:Slave Interface: eno1
35:MII Status: up
39:Link Failure Count: 0
45:Actor Churn State: churned
46:Partner Churn State: churned
64:Slave Interface: eno2
65:MII Status: up
69:Link Failure Count: 0
75:Actor Churn State: churned
76:Partner Churn State: churned
Що це означає: Шукайте переходи churn, зміни кількості портів і помилки лінку. Якщо Number of ports падає до 1 без link-down — винен LACP.
Рішення: Якщо бонд стабільний, але додаток незадоволений — перестаньте звинувачувати LACP і почніть вимірювати втрату пакетів і затримки.
Завдання 5: Підтвердіть швидкість/дуплекс/auto-neg NIC і шукайте флапи там
cr0x@server:~$ ethtool eno1 | egrep -i 'Speed|Duplex|Auto-negotiation|Link detected'
Speed: 25000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
Що це означає: Несподівані зміни швидкості, вимкнений autoneg на одній стороні або перемикання Link detected вказують на фізичну чи конфігураційну невідповідність.
Рішення: Якщо autoneg неузгоджений зі стороною комутатора — виправте це перед тим, як сперечатися про таймери LACP. LACP не зможе домовитися через лінк, який сперечається про фізику.
Завдання 6: Перевірте CRC/FEC/PCS помилки (фізичні сигнатури)
cr0x@server:~$ ethtool --phy-statistics eno1 2>/dev/null | head
PHY statistics for eno1:
Symbol Error During Carrier: 0
Receive Error Count: 0
cr0x@server:~$ ethtool -S eno1 | egrep -i 'crc|fcs|symbol|fec|align|jabber|code|pcs' | head -n 20
rx_crc_errors: 0
rx_fcs_errors: 0
Що це означає: Не кожен драйвер відкриває PHY-статистику. Але якщо ви бачите зростання CRC/symbol/FEC corrections — ви знайшли фізичну проблему, що може проявлятися як нестабільність LACP.
Рішення: Якщо є фізичні помилки — спочатку замініть/очистіть/переключіть кабель. Налаштування програмного забезпечення на поганому волокні — як оптимізувати базу даних на танутьому диску.
Жарт 1: LACP — це протокол стосунків: він стабільний, доки хтось не перестане спілкуватися на одну секунду, потім йому «треба поговорити».
Завдання 7: Виявити версію драйвера/прошивки NIC і шукати відомі проблемні комбінації
cr0x@server:~$ ethtool -i eno1
driver: ice
version: 6.1.0
firmware-version: 4.20 0x8001a3d5
bus-info: 0000:5e:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
Що це означає: Драйвер і прошивка мають значення. Дуже. Тримайте невелику внутрішню матрицю «відомо добрих» версій для вашого обладнання.
Рішення: Якщо цей хост вирізняється у флоті (інша прошивка) — ставте його під підозру. Стандартизація нудна; нудне — надійне.
Завдання 8: Перевірте баланс IRQ, кільця, і пропущені пакети (голод контрол-площини може скидати LACPDU)
cr0x@server:~$ nstat -az | egrep -i 'TcpRetransSegs|IpInDiscards|IpInDelivers|UdpInErrors'
TcpRetransSegs 1823 0.0
IpInDiscards 47 0.0
UdpInErrors 0 0.0
cr0x@server:~$ ip -s link show eno1 | sed -n '1,6p'
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:aa:bb:01 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9876543210 1234567 0 14 0 0
TX: bytes packets errors dropped carrier collsns
1234567890 234567 0 0 0 0
Що це означає: Пропуски RX на NIC можуть включати LACPDU, якщо ситуація погана. Зазвичай LACPDU — малі і рідкісні, але голодування контрол-площини трапляється на перевантажених системах.
Рішення: Якщо хост втрачає пакети під час завантаження CPU або IRQ неправильно приписані — спочатку виправляйте продуктивність хоста, особливо на вузлах зберігання, що роблять багато чекум/крипто/стиснення.
Завдання 9: Підтвердити, що NIC отримує мультикаст-адресу LACP
LACPDUs використовують адресу slow protocols multicast (01:80:c2:00:00:02). Якщо NIC, міст або комутатор фільтрують її несподівано, LACP падає цікаво.
cr0x@server:~$ ip maddr show dev eno1
2: eno1
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
link 01:80:c2:00:00:02
link 33:33:ff:aa:bb:01
Що це означає: Наявність 01:80:c2:00:00:02 обнадіює. Відсутність не завжди фатальна (деякі драйвери не показують її чисто), але якщо її немає і відбуваються флапи — це підказка.
Рішення: Якщо включено фільтрацію мультикасту або особливі функції безпеки (на хості чи комутаторі), перевірте явно, що вони дозволяють slow-protocol кадри.
Завдання 10: Переконайтеся, що обидва slaves мають ідентичні L2 налаштування (MTU, offloads, VLAN-фільтрація)
cr0x@server:~$ for i in eno1 eno2; do echo "== $i =="; ip -d link show $i | egrep -i 'mtu|vf|vlan|state'; ethtool -k $i | egrep -i 'rx-vlan|tx-vlan|gro|gso|tso' | head -n 12; done
== eno1 ==
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
rx-vlan-offload: on
tx-vlan-offload: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
== eno2 ==
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
rx-vlan-offload: on
tx-vlan-offload: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
Що це означає: Асиметрія — постійний злодій. Якщо offload відрізняються або MTU різні — ваш бонд може поводитися «нормально», але періодично втрачати контрольні чи дані кадри під навантаженням.
Рішення: Зробіть slaves максимально ідентичними. Якщо треба змінити offloads — змінюйте на обох і фіксуйте причину.
Завдання 11: Перевірте, що STP/міст не відсікає slow-protocol кадри
Якщо bond0 є частиною мосту (часто на хостах віртуалізації), перевірте налаштування фільтрації, що можуть взаємодіяти з LACP або станом лінку.
cr0x@server:~$ bridge link show
2: eno1 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> master bond0
3: eno2 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> master bond0
cr0x@server:~$ bridge -d vlan show | head
port vlan-id
bond0 10 PVID Egress Untagged
bond0 20
Що це означає: Містування — звичайно нормально; плутати містування з per-port VLAN конфігом — ні. Спрощуйте L2 модель під час відлагодження LACP.
Рішення: Якщо хост робить складне мостування плюс bonding — тимчасово спростіть (вікно техобслуговування), щоб ізолювати, чи сам бонд нестабільний.
Завдання 12: Проведіть керований тест деградації (доведіть, що бонд реагує правильно)
Ось як довести поведінку хоста скептичній мережевій команді: покажіть детерміновану реакцію на примусову подію лінку.
cr0x@server:~$ sudo ip link set dev eno2 down
cr0x@server:~$ cat /proc/net/bonding/bond0 | egrep -A3 'Active Aggregator Info|Number of ports|Slave Interface|MII Status' | head -n 20
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: down
cr0x@server:~$ sudo ip link set dev eno2 up
Що це означає: Ви перевіряєте, що хост чисто видаляє/додає slave і повертається до 2 портів без штормів churn.
Рішення: Якщо цей контрольований тест породжує churn або довго відновлюється — можлива проблема на стороні хоста (ad_select, lacp_rate mismatch або таймінгові проблеми).
Докази зі сторони комутатора: що вимагати від мережевої команди
Ви можете не мати доступу до CLI комутатора. Добре. Вам все одно потрібні факти, а не відчуття. Просіть конкретні виводи і наполягайте, щоб вони покривали обидва членські порти і інтерфейс port-channel.
Ось що вам потрібно, незалежно від вендора:
- Стан port-channel: up/down, учасники bundled чи suspended, коди причин.
- Деталі LACP partner: actor/partner system ID (MAC), ключі, номера портів.
- Лічильники інтерфейсу: CRC/FCS, symbol errors, discards, pause frames, переходи лінку.
- Перевірки консистентності: список VLAN, MTU, швидкість/дуплекс, режим LACP (active/passive), LACP rate.
- Стан MLAG/стека: здоров’я peer link, консистентність, orphan порти.
І все це — з часовою кореляцією з тимчасовими позначками churn на хості.
Які свідчення зі сторони комутатора однозначно вказують на проблему комутатора?
- Комутатор повідомляє, що LACP partner ID змінюється туди-сюди, тоді як системний MAC хоста стабільний.
- Комутатор підвішує учасника через «LACP timeout», але хост-захоплення показує, що він відправляв LACPDU вчасно.
- Комутатор показує зростання CRC/FCS на своєму порту, а хост — ні (або навпаки), що звужує проблемний сегмент.
- Проблеми MLAG peer-link збігаються з флапами, і логи комутатора показують повторні переговори.
Які свідчення зі сторони комутатора вказують на проблему хоста?
- Комутатор бачить прогалини LACPDU від хоста (PDUs не надходять), тоді як хост перевантажений або має скиди NIC/ресет.
- Комутатор повідомляє, що хост відправляє непослідовні ключі або ID портів між учасниками (часто через неправильне бондування, SR-IOV/VF або дрейф конфігурації).
- Логи комутатора показують link down/up на інтерфейсі, що збігається з логами ядра хоста й вказує на оптику/кабель.
Захоплення пакетів: LACPDU майже ніколи не брешуть
Якщо ви хочете доказ, який переживе ревізію змін, захопіть контрольний трафік. LACPDU — це Ethernet-кадри (EtherType 0x8809), що надсилаються на 01:80:c2:00:00:02. Це не IP. Вони не з’являться у вашому tcpdump, якщо ви не попросите правильно.
Завдання 13: Захопіть LACPDU на кожному slave і на bond0 (та порівняйте)
Робіть це під час вікна флапу. Захоплюйте на slaves, бо bond0 може не бачити кожен кадр так, як ви очікуєте.
cr0x@server:~$ sudo timeout 60 tcpdump -i eno1 -e -vvv -s 0 ether proto 0x8809
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.123456 00:11:22:33:44:55 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
Actor System 3c:fd:fe:aa:bb:ff, Actor Key 17, Port 1, State 0x3d
Partner System 00:11:22:33:44:55, Partner Key 51, Port 49, State 0x3f
cr0x@server:~$ sudo timeout 60 tcpdump -i eno2 -e -vvv -s 0 ether proto 0x8809
tcpdump: listening on eno2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.223456 00:11:22:33:44:55 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
Actor System 3c:fd:fe:aa:bb:ff, Actor Key 17, Port 2, State 0x3d
Partner System 00:11:22:33:44:55, Partner Key 51, Port 50, State 0x3f
Що це означає: Ви повинні бачити регулярні LACPDU. Actor System має збігатися з MAC бонду; Partner System — з LACP system ID комутатора. Номери портів мають бути стабільними. Якщо один інтерфейс перестає бачити вхідні LACPDU, а інший продовжує — це звужує проблему до одного фізичного шляху або порту комутатора.
Рішення: Якщо хост відправляє LACPDU (можна також захопити вихідні), але не отримує відповідей на одній ніжці — підозрюйте комутатор/порт/PHY.
Завдання 14: Доведіть, що хост передає LACPDU (вихідні докази)
Тільки вхідні кадри можуть ввести в оману, якщо тільки комутатор говорить. Захопіть напрямок, дивлячись на MAC-адреси і таймінг; tcpdump на Linux не завжди правильно маркує напрямок на всіх драйверах, але MAC підкаже.
cr0x@server:~$ sudo timeout 20 tcpdump -i eno1 -e -vv -s 0 ether proto 0x8809 | head
12:02:00.000001 3c:fd:fe:aa:bb:ff > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
12:02:01.000113 3c:fd:fe:aa:bb:ff > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
Що це означає: Source MAC, що збігається з MAC бонду, вказує, що хост відправляє. Таймінг близький до 1 секунди вказує на LACP fast.
Рішення: Якщо хост відправляє стабільно, а комутатор стверджує «PDUs не отримані» — у вас об’єктивний конфлікт, що зазвичай завершується захопленням на порту комутатора або глибоким аналізом ASIC-лічильників.
Завдання 15: Корелюйте час флапу з прогалинами в LACPDU
cr0x@server:~$ sudo timeout 30 tcpdump -tt -i eno1 -e -s 0 ether proto 0x8809 | awk '{print $1, $2, $3, $4, $5}'
1703851360.000001 3c:fd:fe:aa:bb:ff > 01:80:c2:00:00:02,
1703851361.000104 3c:fd:fe:aa:bb:ff > 01:80:c2:00:00:02,
1703851362.000095 3c:fd:fe:aa:bb:ff > 01:80:c2:00:00:02,
Що це означає: Шукаєте пропущені секунди. Якщо бачите кадри з кроком 1 секунда, потім раптову багатосекундну тишу і бонд churn — це втрата контрол-площини (хост або комутатор).
Рішення: Тиша при стабільному CPU/IRQ і без пропусків вказує на фільтрацію/полісінг на стороні комутатора або мікроглітч фізики, що недостатній для логування link down.
Дерево рішень: комутатор vs хост vs фізика
Випадок A: Ви бачите «Link is Down/Up» в логах хоста
Найімовірніше: фізичний рівень або NIC/драйвер/прошивка. LACP нижче за стан лінку.
Доведіть це:
- Таймстампи журналу ядра показують carrier down/up на конкретному slave.
- ethtool лічильники показують зростання CRC/FCS або інших фізичних помилок.
- Лічильники комутатора співпадають (перехід лінку, помилки).
Дія: Поміняйте кабель/DAC/оптику в контрольованому порядку, почистьте волокно, перемістіть на інший порт комутатора, оновіть прошивку/драйвер NIC, якщо відомо, що вони проблемні.
Випадок B: Carrier залишається up, але склад членів бонду змінюється і лічильники churn ростуть
Найімовірніше: нестабільність переговорів LACP, невідповідність або втрата контрольних кадрів.
Доведіть це:
- /proc/net/bonding показує інкременти стану churn.
- tcpdump показує відсутність LACPDU на одній ніжці або зміну ідентичності партнера.
- Логи port-channel на комутаторі показують «suspended» члени з кодами причин, що збігаються з churn.
Дія: Перевірте режими LACP (active/active — загальноприйнятий вибір), таймери (fast/fast), і симетрію конфігурацій (VLAN/MTU/швидкість) між обома портами комутатора і обома slave на хості.
Випадок C: Все виглядає стабільно, але додатки бачать періодичні втрати/затримки
Найімовірніше: це не LACP. Думайте про буферні скиди, ECN/pause-шторм, хешування або upstream-затор.
Доведіть це:
- Бонд ніколи не змінює склад; немає інкрементів churn; немає link failures.
- Під навантаженням зростають discards інтерфейсу.
- nstat показує збільшення ретрансмітів TCP при стабільному лінку.
Дія: Розгляньте це як інженеринг продуктивності: черги, QoS, MTU, ECN, буфери комутатора і політику хешування.
Цитата (перефразована ідея): застереження у стилі Річарда Фейнмана: реальність перемагає; з законами природи не домовишся.
Три корпоративні міні-історії (анонімізовано)
Міні-історія 1: Інцидент через хибне припущення
У них були пари Debian серверів з 2×10G LACP-бондом до топ-оф-рек пар, що працюють у MLAG. Здавалося, все чисто: bondage «up», port-channel «up», і інцидент почався з знайомої скарги: «записи стрибкоподібні».
Онкал припустив, що це проблема зі сторони зберігання, бо графіки показували IO-латентність. Вони перевіряли черги дисків, налаштовували elevator і навіть обмежували фоновий scrub. Нічого не допомагало. Мережеві інженери наполягали, що port-channel стабільний, бо «up/up». Всі відчували себе продуктивними — ніхто не був правий.
Прорив прийшов від нудної операції: захоплення LACPDU на обох інтерфейсах хоста. Одна ніжка мала чистий 1-секундний каденс; інша показувала сплески і прогалини. Carrier ніколи не падав. Хост фізично не флапав; йому періодично «голодували» контрольні кадри.
Логи комутатора (після запиту з таймстемпами) показали, що під час мікросплесків черга контрольної площини комутатора перевантажувалася іншим некоректно налаштованим пристроєм. LACPDU не були пріоритетними так, як команда вірила. Вони думали, що «контрольні протоколи завжди захищені». В цьому середовищі — ні.
Виправлення не було в ядрі. Воно полягало в ізоляції шумного пристрою і зміні політики комутатора, щоб уникнути голодування slow-protocols. Постмортем-наука була прямою: «up/up» — не SLA, а припущення — не доказ.
Міні-історія 2: Оптимізація, що підвела
Кластер віртуалізації захотів швидший failover. Хтось встановив LACP у fast скрізь, зменшив miimon до 50ms і посилив інші таймери, бо «ми зможемо швидше виявляти відмови». Робили це під час оновлення мережі, де нові комутатори замінили старі; у лабораторії все працювало чудово.
У продакшені почалися періодичні випадкові відключення членів бонду на хостах під високим CPU навантаженням. Не послідовно. Не на кожному хості. Лише на найзавантаженіших гіпервізорах. Це був найгірший тип помилки: та, що спочатку виглядає як чутка, поки не стане подією, що впливає на дохід.
Корінь проблеми — ланцюгова реакція. Fast LACP означав частіші PDU. Низький miimon означав, що бонд дуже швидко реагує. При насиченні CPU частина хостів іноді затримувала обробку receive-інтерруптів досить, що jitter обробки LACPDU виходив за межі толерантності state machine комутатора. Лінки були фізично нормальні. Переговори — ні.
Вони «оптимізували» час відновлення і випадково перетворили звичайний планувальний джиттер у тригер відмови. Повернення до slow rate (або залишення fast, але виправлення IRQ affinity і резерв CPU для мережі) усунуло флапи. Справжнє виправлення — ізоляція ресурсів: тримайте хост у стані, коли контрольний трафік обробляється передбачувано.
Одна корисна ремарка з рев’ю: «Швидкість відновлення — це фіча, доки вона не стане чутливістю». Якщо ви їдете швидко — вимірюйте jitter і втрати, а не лише середню пропускну здатність.
Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію
Фінансова контора запускала Debian на bare metal для pipeline з низькою затримкою. Мережа була проста, але дисциплінована. Кожну версію прошивки NIC відстежували. Кожен port-channel мав стандартний шаблон. Кожна зміна мала знімки лічильників і стану LACP до і після.
Одного тижня новий рік став онлайн, і відразу почався LACP churn на частині серверів. Мережеві інженери підозрювали сервери, бо «решта фабрики в порядку». Серверна команда підозрювала комутатори, бо «сервери ідентичні». Класика.
І тут нудна практика окупилася. Вони порівняли знімок з відомо добрим стійлом: partner system ID, partner key, ID членів портів, базові лічильники помилок. У новому стійлі ключ партнера відрізнявся на одному порті. Такий розбіжний oper key — не «Linux веде себе дивно». Це помилка консистентності конфігурації комутатора.
Мережева команда знайшла, що один з пар MLAG мав старіший шаблон: список VLAN і LACP key відрізнялися, тож комутатор чергував між bundle і suspend залежно від того, який peer був primary. Це не було драматично, щоб впасти весь port-channel — але достатньо, щоб під навантаженням створювати churn.
Виправили конфіг і флапи зупинилися. Без героїчних дій. Без гадань. Лише знімки базового стану і наполегливість щодо симетрії. Нудне — не відсутність майстерності; це її результат.
Поширені помилки: симптом → причина → виправлення
1) Симптом: Один slave багаторазово «suspended» на комутаторі; хост показує churned
Причина: Невідповідність режиму/таймерів LACP (active/passive, fast/slow) або різний LACP key/VLAN/MTU між member портами.
Виправлення: Зробіть обидві сторони симетричними. Використовуйте LACP active на обох кінцях, якщо немає політичної причини інакше. Вирівняйте LACP rate. Перевірте VLAN/MTU/швидкість на обох портах комутатора у бандлі.
2) Симптом: Бонд втрачає члена без повідомлень «Link is Down»
Причина: Втрата LACPDU, фільтрація slow-protocol або перевантаження control-plane комутатора. В MLAG — нестабільність peer-link, що змінює ідентичність партнера.
Виправлення: Захопіть LACPDU на обох slave; вимагайте логи комутатора з кодами причин. Перевірте здоров’я MLAG/стека і обробку slow-protocol кадрів.
3) Симптом: Журнали ядра показують скиди NIC, тайм-аути або TX hang під час флапів
Причина: Проблема на боці хоста: драйвер/прошивка, помилки PCIe або дивності енергозбереження.
Виправлення: Оновіть прошивку NIC до відомої робочої версії, перевірте PCIe AER логи, вимкніть проблемні режими енергозбереження і перевірте BIOS налаштування щодо PCIe ASPM, якщо релевантно.
4) Симптом: CRC/FCS помилки ростуть на одному інтерфейсі; потім йде LACP churn
Причина: Поганий кабель/DAC/оптика, брудне волокно, граничний трансивер або проблемний порт.
Виправлення: Замініть фізичні компоненти в контрольованому порядку (спочатку кабель, потім оптика, потім порт). Фіксуйте, яка зміна змінила лічильники. Якщо не вимірюєте — ви просто переупорядковуєте місце злочину.
5) Симптом: Пропускна здатність наполовину від очікуваної, але флапів немає
Причина: Хешування (один великий потік), неправильний xmit_hash_policy або розподіл потоків вище по ланцюжку.
Виправлення: Підтвердьте очікуваний характер трафіку. Використовуйте layer3+4 хешування для загальних серверів. Для протоколів зберігання перевірте, чи у вас багато потоків або кілька великих.
6) Симптом: Флапи відбуваються лише під час пікового CPU навантаження
Причина: Хост не встигає обробляти контрольний трафік (IRQ imbalance, голодування CPU), що викликає пропуски LACPDU і тайм-аути.
Виправлення: Виправте ізоляцію ресурсів хоста: прикріпіть IRQ, перевірте політику irqbalance, збільшіть розмір кільцевих буферів при потребі і уникайте «оптимізацій» таймерів, що зменшують толерантність.
Жарт 2: port-channel — як корпоративне злиття: якщо обидві сторони не погодять документи, ви отримаєте «синергію» і відключення.
Чек-листи / поетапний план
Покроково: сформуйте «пакет доказів» для відповідальності комутатора чи хоста
- Зафіксуйте часове вікно: початкові і кінцеві таймстемпи в UTC. Якщо команди не погоджують час — вони не погодять і реальність.
- Знімок хоста: збережіть /proc/net/bonding/bond0 до, під час і після.
- Логи хоста: journalctl -k навколо вікна; grep по link і driver подіях.
- Лічильники хоста: ethtool -S для кожного slave; ip -s link для drops.
- Конфігураційна правда хоста: /sys/class/net/bond0/bonding/* плюс ip -d link show.
- Захоплення LACPDU: 60 секунд на кожному slave під час флапу.
- Запит до комутатора: попросіть стан port-channel, коди причин per-member, partner ID/key і лічильники помилок за ті ж таймстемпи.
- Кореляція: таймстемпи збігаються? та сама ніжка поводиться погано постійно?
- Ізоляція: переміщуйте кабель/оптику/порт по одному, якщо підозрюєте фізику; тестуйте повторно.
- Рішення і виправлення: прийміть гіпотезу і підтвердіть зміною + вимірюванням.
Покроково: фізична ізоляція без погіршення ситуації
- Визначте «погану ніжку» по churn/лічильниках/захопленнях (eno1 vs eno2).
- Замініть тільки кабель/DAC на тій ніжці; не змінюйте обидва одночасно.
- Повторно перевірте базовий рівень CRC/FCS, потім після 10 хвилин під навантаженням.
- Якщо ще погано — замініть оптику, потім перемістіться на інший порт, потім на іншу line card, якщо можливо.
- Документуйте кожну зміну до/після лічильниками. Це запобігає «я не знаю, що допомогло» фольклору.
Покроково: аудит симетрії конфігурації (хост + комутатор)
- Хост: обидва slaves однакові MTU, однакові offloads, однакова швидкість/дуплекс/autoneg, однаковий клас драйвера/прошивки.
- Хост: режим bond 802.3ad, стабільний ad_select, санкціонований miimon і lacp_rate, що відповідає очікуванню комутатора.
- Комутатор: обидва member-порти мають ідентичний список VLAN, MTU, режим LACP, LACP rate і знаходяться в одному port-channel.
- MLAG: обидва комутатори мають ідентичний port-channel конфіг і peer-link здоровий; немає «orphaned» невідповідностей.
FAQ
1) Чи Debian 13 тут особливий, чи це просто «Linux bonding»?
Здебільшого це питання Linux bonding. Debian 13 важливий тим, що версії ядра/драйверів змінюють поведінку, а systemd-networkd vs ifupdown змінює, як виникає дрейф конфігурації.
2) Який єдиний найкращий файл дивитися для проблем LACP на хості?
/proc/net/bonding/bond0. Він показує churn, ідентичність партнера, ключі, номера портів і Link Failure Count. Це найближче до «чорної скриньки».
3) Якщо комутатор каже, що port-channel up — чи може він бути зламаний?
Так. «Up» може означати «хоча б один учасник bundled». Ви все ще можете мати одну ніжку suspended, що флапає або має помилки. Просіть per-member стан і коди причин.
4) Використовувати LACP fast чи slow?
Fast — якщо ви гарантуєте, що контрольний трафік не буде скидатися і хости не будуть голодні; slow — якщо потрібна толерантність. Якщо використовуєте fast — вимірюйте jitter і втрати, а не лише стан лінку.
5) Як довести, що хост відправляє LACPDU?
tcpdump на slave з EtherType 0x8809, перевірка source MAC на відповідність MAC бонду і каденсу, що відповідає lacp_rate.
6) Як довести, що комутатор відправляє LACPDU у відповідь?
Те саме захоплення, але шукайте кадри з source MAC LACP системи комутатора. Якщо бачите вихідні кадри хоста, але відсутні вхідні на одній ніжці — сильний доказ.
7) Чи може поганий кабель спричинити флапи LACP без подій link down?
Так. Ви можете отримати помилки і мікро-переривання, що не викликають падіння carrier достатньо довго для логування link down, але руйнують обмін LACPDU і якість трафіку.
8) Чи політика хешування викликає флапи?
Ні, політика хешування зазвичай викликає проблеми з продуктивністю, а не переговорним churn. Але продуктивні проблеми часто помилково звинувачують у «флапах». Перевіряйте /proc/net/bonding і лічильники churn.
9) Якщо тільки один хост у стояку флапає, а інші в порядку?
Підозрюйте відмінності прошивки/драйвера хоста, проблемний порт NIC або кабель/оптику. Далі — підозра на один порт комутатора. Використовуйте лічильники і ізоляцію «поганої ніжки».
10) Якщо одночасно флапають кілька хостів на парі комутаторів?
Зачепіть комутатор першочергово: MLAG peer-link, перевантаження контрольної площини, неправильний шаблон або баг софту. Просіть логи комутатора за ті ж таймстемпи і порівнюйте partner/key поведінку.
Висновок: практичні наступні кроки
Коли LACP-бонди флапають, перемагає методичність, а не голосність. Почніть з простішої класифікації: carrier flapping проти LACP churn при стабільному carrier. Потім зберіть три види доказів, що витримають міжкомандні суперечки: журнали ядра, лічильники і захоплення пакетів.
Наступні кроки, що зазвичай завершують дискусію:
- Захопіть 60 секунд LACPDU на кожному slave під час флапу.
- Експортуйте /proc/net/bonding/bond0 до/під час/після і корелюйте з логами комутатора.
- Порівняйте CRC/FCS і discards на хості та портах комутатора, щоб звузити проблемний сегмент.
- У maintenance-вікні примусово опустіть/підніміть один slave, щоб перевірити детерміновану поведінку хоста.
- Якщо MLAG — вимагайте докази здоров’я peer-link і симетрії конфігурацій, а не усні запевнення.
Робіть так — і ви припините «трубити» про проблему та почнете її доводити. У продакшені це різниця між вирішенням проблеми і її відтермінуванням на наступний тиждень.