Lorsqu’un bond LACP flappe, ce n’est pas un échec bruyant. C’est un échec comme un comité : intermittent, plausible et toujours pendant votre heure de pointe. Une minute vous avez un bundle 2×25G sain ; la minute suivante votre trafic de stockage est cantonné sur un seul lien, TCP retransmet et la phrase préférée de tout le monde apparaît dans le chat : « Ça doit être le réseau. »
Ce guide de terrain s’adresse aux opérateurs Debian 13 qui doivent faire quelque chose de plus rare que dépanner : prouver. Prouver si l’hôte se comporte mal, si le switch est mal configuré, ou si la couche physique transforme discrètement votre LACP en danse interprétative.
Playbook de diagnostic rapide
Si vous n’avez que 15 minutes avant que quelqu’un ne propose de rebooter le cœur, faites ceci dans l’ordre. Le but est de séparer « problème de négociation LACP » de « problème de carrier/PHY » et de « la pile réseau hôte a fait un truc bizarre ».
1) Confirmer s’il s’agit d’un flapping carrier ou d’un flapping d’état LACP
Carrier down/up pointe vers l’optique/câble/ASIC/driver/firmware. Des changements d’état LACP alors que le carrier est stable indiquent un mismatch de configuration, des timers, des problèmes MLAG/stack ou une perte de 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>
Ce que ça signifie : Si un esclave montre DOWN ou manque LOWER_UP pendant la fenêtre de flap, vous poursuivez quelque chose de physique/driver. Si les esclaves restent UP mais bond0 perd des membres actifs, vous êtes sur de la négociation LACP ou de la livraison de LACPDU.
Décision : Si le carrier tombe, sautez aux compteurs et vérifications de la couche physique avec ethtool. Si le carrier est stable, concentrez-vous sur LACPDU, les timers et la cohérence du switch.
2) Récupérer l’état du driver de bonding et les indicateurs de « dernière agitation »
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
Ce que ça signifie : « Churned » et des compteurs de churn qui augmentent sont votre preuve flagrante d’une instabilité de négociation LACP ou d’une perte de LACPDU. Une augmentation de Link Failure Count est plus physique/driver. Le MAC partenaire, les clés et les numéros de port sont l’identité de l’autre côté telle que le voit l’hôte.
Décision : Si les compteurs de churn augmentent alors que MII reste up, exigez les logs LACP côté switch et vérifiez la portée des LACPDU via capture.
3) Vérifier les logs du kernel pour resets NIC, problèmes PCIe ou events 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
Ce que ça signifie : Le kernel vous dénoncera volontiers. « Link is Down/Up » = carrier. « TX hang/reset/firmware » = côté hôte. Churn sans lien down suggère mismatch LACP ou perte de LACPDU.
Décision : Si vous voyez des resets/timeouts, arrêtez de discuter de la config du switch et commencez à regarder driver/firmware et la santé PCIe.
4) Obtenir les compteurs d’erreurs sur les NIC esclaves
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
Ce que ça signifie : CRC/FCS/symbol errors pointent fortement vers la couche physique (optiques, câble, fibre sale, DAC marginal). Les discards peuvent venir de congestion, buffers, ou du comportement du switch.
Décision : Si CRC/FCS augmente pendant les flaps, traitez le chemin physique comme coupable jusqu’à preuve du contraire.
5) Si toujours flou, capturer les LACPDU pendant 60 secondes durant le problème
Nous en reparlerons plus bas, mais c’est le moyen le plus rapide pour montrer « l’hôte a envoyé LACPDU ; le switch n’a pas répondu » (ou vice versa).
Ce que « flapping LACP » signifie réellement
En mode bonding Linux 802.3ad, « flapping » signifie généralement que le bond change de façon répétée quelles interfaces esclaves sont en mode collecting/distributing. Cela peut arriver alors que les liens physiques restent up. Cela peut aussi arriver parce que les liens physiques tombent réellement, auquel cas LACP n’est que le messager touché par les tirs.
Opérationnellement, vous verrez :
- Un esclave retiré/rajouté de façon répétée à l’aggregator actif.
- Le MAC partenaire ou la Partner Key qui change de façon inattendue (souvent à cause d’MLAG/stack bizarre).
- Débit en dents de scie, pics de latence stockage, retransmissions TCP et « pourquoi la moitié de ma capacité a disparu ? ».
LACP a des timers. LACP a des machines d’état. LACP a aussi l’habitude de révéler chaque incohérence dont vous ne soupçonniez pas l’existence. L’astuce est de collecter des preuves qui tiennent face au débat inter-équipes : logs, compteurs et trames sur le câble.
Faits intéressants et contexte (court, concret)
- LACP est normalisé dans IEEE 802.1AX ; de nombreux documents et outils continuent à parler d’IEEE 802.3ad, qui a été intégré à 802.1AX.
- Le taux « fast » LACP est d’environ 1 seconde entre LACPDUs ; « slow » est autour de 30 secondes. « Fast » détecte les problèmes plus vite — et amplifie aussi les problèmes de perte de paquets.
- Le bonding Linux précède la culture moderne « network stack as code » ; /proc/net/bonding reste l’un des fichiers de diagnostic les plus utiles sur le système.
- Beaucoup de switches traitent LACP comme du trafic control-plane avec des règles de queueing différentes de la data ; la congestion ou le policing peuvent dropper des LACPDUs alors que les données « marchent presque ».
- Les implémentations MLAG diffèrent grandement ; certaines gèrent l’identité partenaire et le keying d’une manière qui embrouille les hosts lors de bascules si la config n’est pas parfaitement symétrique.
- La politique de hachage d’émission compte plus qu’on l’admet ; « layer2 » peut épingler les flux étrangement en environnements virtualisés, tandis que « layer3+4 » peut rompre des attentes avec NAT ou routage asymétrique.
- L’agrégation de liens ne somme pas la bande passante pour un flux TCP unique sauf cas particuliers ; la plupart des déploiements reposent sur du hashing par flux.
- Carrier up ne garantit pas une couche physique propre ; vous pouvez avoir un lien stable avec des CRC intermittents qui déclenchent churn et retransmissions en couches supérieures.
- Certaines offloads NIC ont historiquement interagi mal avec le bonding (surtout autour du VLAN offload et certaines versions de drivers) ; le mode d’échec ressemble à « le réseau est instable ».
Éléments prouvant côté hôte : vérifications Debian 13 utilisables en post-mortem
Debian 13 vous offre un kernel moderne, systemd et la boîte à outils Linux habituelle. Utilisez-les comme si vous montiez un dossier d’enquête, pas comme si vous jouiez au whack-a-mole.
Tâche 1 : Identifier qui configure le bond (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
Ce que ça signifie : Vous devez connaître le plan de contrôle. Si deux gestionnaires se disputent, vous obtenez des « flaps » qui sont en réalité des événements de reconfiguration.
Décision : Si plus d’un est actif, en choisissez un et désactivez les autres avant de faire quoi que ce soit. Déboguer une cible mouvante est un hobby, pas une pratique SRE.
Tâche 2 : Afficher la configuration du bond telle que le kernel la voit
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
Ce que ça signifie : C’est la vérité telle que le kernel l’applique, pas ce que prétend votre fichier de configuration. lacp_rate « 1 » est fast.
Décision : Si miimon est 0 et que vous comptez sur la détection carrier, vous faites confiance aux notifications driver. Ça peut aller, mais soyez explicite.
Tâche 3 : Vérifier les esclaves et la présence d’un mismatch VLAN-sur-esclave vs VLAN-sur-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>
Ce que ça signifie : Vous voulez des VLANs au-dessus de bond0, pas individuellement sur les esclaves (sauf design très spécifique et config switch correspondante). « ip -d » montre les paramètres du bond et le MTU.
Décision : Si le MTU diffère entre esclaves ou avec le switch, vous ne verrez peut-être pas des « flaps », mais vous verrez des symptômes similaires. Corrigez la cohérence MTU tôt.
Tâche 4 : Surveiller l’état du bond en direct pendant le flap
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
Ce que ça signifie : Vous recherchez des transitions de churn, des changements du nombre de ports et des échecs de lien. Si le nombre de ports tombe à 1 sans link-down, LACP est coupable.
Décision : Si le bond est stable mais l’application est mécontente, arrêtez de blâmer LACP et commencez à mesurer perte de paquets et latence.
Tâche 5 : Confirmer la vitesse/duplex/autonégociation NIC et vérifier des flaps là
cr0x@server:~$ ethtool eno1 | egrep -i 'Speed|Duplex|Auto-negotiation|Link detected'
Speed: 25000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
Ce que ça signifie : Des changements de vitesse inattendus, autoneg désactivé d’un côté, ou Link detected qui bascule pointent vers du physique ou un mismatch de configuration.
Décision : Si autoneg est mismatché avec le switch, corrigez cela avant de vous disputer sur les timers LACP. LACP ne peut pas négocier sur un lien qui se dispute sur la physique.
Tâche 6 : Vérifier CRC/FEC/PCS (preuves physiques évidentes)
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
Ce que ça signifie : Tous les drivers n’exposent pas les stats PHY. Mais si vous voyez CRC/symbol/FEC corrections monter, vous avez trouvé un problème physique qui peut se présenter comme une instabilité LACP.
Décision : Si des erreurs physiques sont présentes, remplacez/nettoyez/rebranchez d’abord. Optimiser le logiciel autour d’une fibre défaillante revient à optimiser une base de données sur un disque mourant.
Blague 1 : LACP est un protocole de relation : il est stable jusqu’à ce que quelqu’un cesse de communiquer pendant une seconde, puis il « a besoin de parler ».
Tâche 7 : Détecter la version du driver/firmware NIC et rechercher des combinaisons connues mauvaises
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
Ce que ça signifie : Driver et firmware comptent. Beaucoup. Gardez une petite matrice interne des versions « connues bonnes » pour votre matériel.
Décision : Si cet hôte est un outlier par rapport à la flotte (firmware différent), considérez-le suspect. La standardisation est ennuyeuse ; l’ennui est fiable.
Tâche 8 : Vérifier l’équilibrage IRQ, les ring buffers et paquets perdus (la famine du plan de contrôle peut dropper des 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
Ce que ça signifie : Des RX drops sur la NIC peuvent inclure des LACPDUs si la situation est suffisamment mauvaise. Habituellement les LACPDUs sont petits et rares, mais la famine arrive sur des systèmes surchargés.
Décision : Si l’hôte perd des paquets alors que le CPU est saturé ou que les IRQ sont mal réparties, corrigez la performance hôte d’abord — surtout sur des nœuds de stockage faisant beaucoup de checksum/crypto/compression.
Tâche 9 : Confirmer que la réception MAC multicast LACP n’est pas filtrée
Les LACPDUs utilisent l’adresse multicast slow protocols (01:80:c2:00:00:02). Si votre NIC, bridge ou switch la filtre de façon inattendue, LACP échoue de manières bizarres.
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
Ce que ça signifie : Voir 01:80:c2:00:00:02 est rassurant. L’absence n’est pas toujours fatale (certains drivers l’affichent mal), mais si elle manque et que ça flappe, c’est un indice.
Décision : Si le filtrage multicast ou des fonctions de sécurité spéciales sont activées (côté hôte ou switch), validez explicitement qu’elles laissent passer les trames slow-protocols.
Tâche 10 : Valider que les deux esclaves ont des réglages L2 identiques (MTU, offloads, filtrage 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
Ce que ça signifie : L’asymétrie est un coupable récurrent. Si les offloads diffèrent, ou le MTU diffère, votre bond peut se comporter « bien » mais laisser tomber des trames de contrôle ou données sous charge.
Décision : Rendre les esclaves aussi identiques que possible. Si vous devez changer des offloads, changez-les sur les deux et enregistrez pourquoi.
Tâche 11 : Vérifier que STP/bridge n’avalent pas les trames slow-protocol
Si bond0 fait partie d’un bridge (commun sur des hosts de virtualisation), vérifiez les réglages de filtrage qui interagissent avec LACP ou l’état de lien.
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
Ce que ça signifie : Le bridging est correct ; confondre bridging et config VLAN par port ne l’est pas. Simplifiez votre modèle L2 lors du debug LACP.
Décision : Si l’hôte réalise un bridging complexe plus bonding, simplifiez temporairement (fenêtre de maintenance) pour isoler si le bond lui-même est instable.
Tâche 12 : Exécuter un test de dégradation contrôlée (prouver que le bond réagit correctement)
C’est ainsi que vous prouvez le comportement hôte à une équipe réseau sceptique : montrer des réactions déterministes à un événement link forcé.
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
Ce que ça signifie : Vous vérifiez que l’hôte retire/ajoute proprement un esclave et revient à 2 ports sans tempête de churn.
Décision : Si ce test contrôlé génère du churn ou met longtemps à réintégrer, vous avez peut-être des problèmes de config hôte (ad_select, lacp_rate mismatch, ou problèmes de timers).
Éléments prouvant côté switch : ce qu’il faut demander à l’équipe réseau
Vous n’avez peut-être pas d’accès CLI au switch. Très bien. Vous avez toujours besoin de faits switch, pas d’impressions. Demandez des sorties spécifiques et insistez pour qu’elles couvrent les deux ports membres et l’interface port-channel.
Voici ce que vous voulez, quel que soit le vendor :
- État du port-channel : up/down, membres agrégés ou suspendus, codes de raison.
- Détails partenaire LACP : actor/partner system ID (MAC), clés, numéros de port.
- Compteurs d’interface : CRC/FCS, erreurs symbol, discards, trames pause, transitions de lien.
- Vérifications de cohérence : liste VLAN, MTU, speed/duplex, mode LACP (active/passive), lacp rate.
- État MLAG/stack si pertinent : santé du peer link, cohérence, ports orphelins.
Et vous voulez que ce soit corrélé temporellement avec les timestamps de churn de l’hôte.
Quelles preuves côté switch impliquent de façon concluante le switch ?
- Le switch rapporte un changement d’ID partenaire LACP en va-et-vient alors que le MAC système de l’hôte reste stable.
- Le switch suspend un membre pour « LACP timeout » mais la capture hôte montre qu’il a transmis des LACPDUs selon le calendrier.
- Le switch montre CRC/FCS croissants sur son compteur de port tandis que l’hôte ne les présente pas (ou inversement), ce qui restreint le segment fautif.
- Des problèmes de peer-link MLAG coïncident avec les flaps, et les logs switch montrent des événements de renégociation.
Quelles preuves côté switch impliquent l’hôte ?
- Le switch voit des trous dans les LACPDU provenant de l’hôte (pas de PDUs reçus) alors que l’hôte est surchargé ou subit des resets NIC.
- Le switch rapporte que l’hôte envoie des clés ou IDs de port incohérents entre membres (souvent dû à un malbonding, SR-IOV/VFs, ou dérive de configuration).
- Les logs switch montrent link down/up qui correspondent aux logs kernel hôte et pointent vers l’optique/câble.
Capture de paquets : les LACPDU ne mentent pas (beaucoup)
Si vous voulez une preuve qui tient lors d’une revue de changement, capturez le trafic de contrôle. Les LACPDUs sont des trames Ethernet (EtherType 0x8809) envoyées à 01:80:c2:00:00:02. Ce n’est pas de l’IP. Elles n’apparaîtront pas dans vos filtres tcpdump à moins que vous ne les demandiez explicitement.
Tâche 13 : Capturer les LACPDUs sur chaque esclave et sur bond0 (et comparer)
Faites-le pendant une fenêtre de flap. Capturez sur les esclaves, parce que bond0 peut ne pas voir chaque trame comme vous l’attendez.
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
Ce que ça signifie : Vous devriez voir des LACPDUs réguliers. Actor System doit correspondre à votre MAC de bond ; Partner System doit correspondre à l’ID LACP du switch. Les numéros de port doivent être stables. Si une interface cesse de voir des LACPDUs entrants alors que l’autre continue, cela isole le problème à un chemin physique ou un port switch.
Décision : Si l’hôte envoie des LACPDUs (vous pouvez aussi capturer les sorties) mais ne reçoit pas de réponses sur une jambe, le switch/port/chemin PHY est suspect.
Tâche 14 : Prouver que l’hôte transmet des LACPDUs (preuve sortante)
Se baser sur les entrants seulement peut être trompeur si seul le switch parle. Capturez directionnellement en observant simplement les MAC source et le timing ; tcpdump Linux n’étiquette pas toujours la direction de façon fiable selon les drivers, mais les MAC le font.
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
Ce que ça signifie : Source MAC égale à votre MAC de bond indique que l’hôte envoie. Un timing proche de 1 seconde implique LACP fast.
Décision : Si l’hôte envoie de façon consistante mais que le switch prétend « pas de PDUs reçus », vous avez maintenant un conflit objectif qui se termine généralement par une capture côté switch ou une plongée dans les compteurs ASIC.
Tâche 15 : Corréler l’heure du flap avec des trous dans les 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,
Ce que ça signifie : Vous recherchez des secondes manquantes. Si vous voyez une cadence d’une seconde puis un silence de plusieurs secondes et que le bond chancelle, vous avez une perte du plan de contrôle (hôte ou switch).
Décision : Le silence avec CPU/IRQ stable et sans drops suggère un filtrage/policing côté switch ou un glitch physique trop court pour déclencher link down.
Arbre de décision : switch vs hôte vs physique
Cas A : Vous voyez « Link is Down/Up » dans les logs hôte
Plus probable : couche physique ou NIC/driver/firmware. LACP est en aval de l’état du lien.
Prouvez-le :
- Les timestamps kernel montrent carrier down/up sur un esclave spécifique.
- Les compteurs ethtool montrent CRC/FCS ou autres erreurs physiques qui augmentent.
- Les compteurs interface switch correspondent (transitions de lien, erreurs).
Action : swappez câble/DAC/optique, nettoyez la fibre, changez de port switch, mettez à jour firmware/driver NIC si connu problématique.
Cas B : Le carrier reste up, mais l’appartenance au bond change et les compteurs de churn augmentent
Plus probable : instabilité de négociation LACP, mismatch, ou perte de trames du plan de contrôle.
Prouvez-le :
- /proc/net/bonding montre des incréments d’état churned.
- tcpdump montre des LACPDUs manquants sur une jambe, ou des changements d’identité partenaire.
- Les logs port-channel du switch montrent des « suspended » avec des raisons alignées sur le churn.
Action : validez le mode LACP (active/active est la valeur sensée par défaut), les timers (fast/fast) et la symétrie de configuration (VLAN/MTU/speed) sur les deux ports switch et les deux esclaves hôte.
Cas C : Tout semble stable, mais les applis voient des pertes/latences intermittentes
Plus probable : pas du LACP. Pensez à des drops de buffers, ECN/pause storms, skew de hashing, ou congestion en amont.
Prouvez-le :
- Le bond ne change jamais d’appartenance ; pas d’incréments de churn ; pas de failures de lien.
- Les drops d’interface augmentent sous charge.
- nstat montre des retransmissions qui montent alors que le lien reste up.
Action : traitez cela comme de l’ingénierie de performance : queues, QoS, MTU, ECN, buffers switch, et politique de hashing.
Citation (idée paraphrasée), attribuée : Avertissement sur la fiabilité dans l’esprit de Richard Feynman : la réalité gagne ; vous ne pouvez pas négocier avec les lois de la nature.
Trois mini-récits d’entreprise (anonymisés)
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Ils avaient une paire de nœuds de stockage Debian, chacun avec un bond LACP 2×10G vers une paire d’armoires top-of-rack en MLAG. Tout semblait propre : bonds « up », port-channels « up », et l’incident démarra par la plainte familière : « les écritures piquent ».
Le service on-call supposa que c’était côté stockage car les graphes montraient de la latence IO. Ils inspectèrent les queues disque, ajustèrent les elevators, et throttlèrent même un scrub en arrière-plan. Rien ne changea. L’équipe réseau affirmait que le port-channel était stable parce qu’il était « up/up ». Tout le monde se sentait productif et personne n’avait raison.
La percée vint en faisant la chose ennuyeuse : capturer les LACPDUs sur les deux interfaces hôte. Une jambe avait une cadence propre d’1 seconde ; l’autre montrait des rafales suivies de trous. Le carrier ne tombait jamais. L’hôte ne « flappait » pas physiquement ; il était intermittemment privé de trafic de contrôle.
Les logs switch (une fois demandés avec timestamps) montrèrent que pendant des micro-bursts, la queue control-plane du switch était frappée par une tempête d’autres trames slow-protocol provenant d’un équipement aval mal configuré. Les LACPDUs n’étaient pas priorisés comme l’équipe le supposait. Ils avaient supposé que « les protocoles de contrôle sont toujours protégés ». Dans cet environnement, ils ne l’étaient pas.
La correction ne fut pas un tweak kernel. Ce fut d’isoler l’équipement bruyant et d’ajuster la politique du switch pour éviter la famine slow-protocol. Le postmortem fut clair : « up/up » n’est pas un SLA, et les hypothèses ne sont pas des preuves.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Un cluster de virtualisation voulait une bascule plus rapide. Quelqu’un avait mis LACP en fast partout, réduit miimon à 50ms, et resserré d’autres timers car « on peut détecter la panne plus vite ». Ils firent cela lors d’un rafraîchissement réseau avec de nouveaux switches en remplacement des anciens, et les tests lab avaient l’air excellents.
En production, ils commencèrent à voir des drops intermittents de membres de bond sur des hôtes sous forte charge CPU. Pas systématiquement. Pas sur tous les hôtes. Seulement sur les hyperviseurs les plus occupés. C’était le pire type d’échec : le genre qui ressemble à une rumeur jusqu’à devenir un incident financier.
La cause racine fut une réaction en chaîne. LACP fast impliquait plus de PDUs fréquents. Miimon faible faisait réagir le bond rapidement à la moindre indication de problème. Sous saturation CPU, un sous-ensemble d’hôtes retardait parfois le traitement des interrupts de réception suffisamment pour que la gestion des LACPDU ait une gigue dépassant la tolérance de la machine d’état du switch. Les liens étaient physiquement sains. La négociation ne l’était pas.
Ils avaient « optimisé » la bascule et transformé par inadvertance la gigue d’ordonnancement normale en déclencheur d’incident. Revenir à slow rate (ou garder LACP fast mais corriger l’affinité IRQ hôte et réserver du CPU pour le réseau) élimina les flaps. La vraie correction fut l’isolation des ressources : garder l’hôte sain pour que le trafic de contrôle soit traité de façon prévisible.
L’une des rares phrases utiles du rapport : « La vitesse de bascule est une fonctionnalité jusqu’à ce qu’elle devienne une sensibilité. » Si vous allez vite, mesurez la gigue et la perte, pas seulement l’état du lien.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation
Un établissement financier utilisait Debian sur du bare metal pour un pipeline sensible à la latence. Leur réseau n’était pas sophistiqué, mais il était discipliné. Chaque version de firmware NIC était suivie. Chaque port-channel switch avait un template standard. Chaque changement avait des snapshots compteurs et état partenaire LACP avant/après.
Une semaine, une nouvelle armoire fut mise en production et commença immédiatement à voir du churn LACP sur un sous-ensemble de serveurs. L’équipe réseau soupçonna les serveurs car « le reste du tissu est sain ». L’équipe serveur soupçonna les switches car « les serveurs sont identiques ». Classique.
Puis la pratique ennuyeuse paya. Ils comparèrent le snapshot pré/post d’une armoire connue bonne : partner system ID, partner key, IDs ports membres, compteurs d’erreur en baseline. Dans la nouvelle armoire, la partner key était différente sur un port membre. Même port-channel ID, clé opérationnelle différente. Ça n’est pas « Linux qui délire ». C’est une erreur de cohérence de configuration switch.
L’équipe réseau trouva qu’un switch de la paire MLAG avait un ancien template appliqué : liste VLAN et key LACP différaient, donc le switch alternait entre agréger et suspendre selon quel pair était primaire au moment. Ce n’était pas assez dramatique pour tomber tout le port-channel — juste suffisant pour churner sous charge.
Ils corrigèrent la config et les flaps cessèrent. Pas d’héroïsme. Pas de suppositions. Juste des snapshots de baseline et l’exigence de symétrie. L’ennui n’est pas un manque de compétence ; c’est le résultat de celle-ci.
Erreurs courantes : symptômes → cause racine → correction
1) Symptom : Un esclave est « suspendu » sur le switch de façon répétée ; l’hôte montre un état churned
Cause racine : mismatch de mode/timer LACP (active/passive, fast/slow) ou clé LACP/VLAN/MTU incohérente entre ports membres.
Correction : Rendre les deux côtés symétriques. Utiliser LACP active sur les deux extrémités sauf contrainte. Aligner le lacp_rate. Vérifier VLAN/MTU/speed identiques sur les deux ports switch du bundle.
2) Symptom : Le bond perd un membre sans aucun message « Link is Down »
Cause racine : perte de LACPDU, filtrage slow-protocol, ou congestion control-plane du switch. En MLAG, cela peut venir d’une instabilité du peer-link causant des changements d’identité partenaire.
Correction : Capturer les LACPDUs sur les deux esclaves hôte ; demander les logs switch avec codes raison. Valider la santé MLAG/stack et le traitement des slow-protocol.
3) Symptom : Les logs kernel montrent resets NIC, timeouts ou TX hangs pendant les flaps
Cause racine : problème driver/firmware hôte, erreurs PCIe, ou bizarreries power management.
Correction : Mettre à jour le firmware NIC vers votre baseline connue bonne, vérifier les logs PCIe AER, désactiver les économies d’énergie problématiques, et valider les réglages BIOS pour PCIe ASPM si pertinent.
4) Symptom : Les CRC/FCS augmentent sur une interface ; le churn LACP suit
Cause racine : câble/DAC/optique défectueux, fibre sale, transceiver marginal, ou port défaillant.
Correction : Swappez les composants physiques dans un ordre contrôlé (d’abord câble, puis optique, puis port). Enregistrez quel changement a modifié les compteurs. Si vous ne mesurez pas, vous ne faites que réarranger la scène de crime.
5) Symptom : Le débit est la moitié de l’attendu, mais pas de flaps
Cause racine : skew de hashing (un flux unique trop gros), mauvais xmit_hash_policy, ou distribution amont qui ne correspond pas.
Correction : Confirmer le pattern de trafic attendu. Utiliser layer3+4 pour un serveur généraliste. Pour les protocoles de stockage, valider si vous poussez beaucoup de flux ou quelques gros flux.
6) Symptom : Les flaps n’arrivent qu’en période de charge CPU élevée
Cause racine : l’hôte ne peut pas traiter le trafic de contrôle de façon fiable (déséquilibre IRQ, famine CPU, drops), causant des trous LACPDU et timeouts.
Correction : Corriger l’isolation des ressources hôte : pinner les IRQs, s’assurer que la politique irqbalance est sensée, augmenter les ring buffers si nécessaire, et éviter les « optimisations » de timers qui réduisent la tolérance.
Blague 2 : Un port-channel, c’est comme une fusion d’entreprise : si les deux parties ne sont pas d’accord sur le papier, vous obtenez de la « synergie » et des pannes.
Listes de contrôle / plan étape par étape
Étape par étape : constituer un « paquet de preuves » pour la responsabilité switch vs hôte
- Enregistrer la fenêtre temporelle : timestamps de début/fin en UTC. Si les équipes ne s’accordent pas sur l’heure, elles ne s’accorderont pas sur la réalité.
- Snapshot hôte : capturer /proc/net/bonding/bond0 avant, pendant, après.
- Logs hôte : journalctl -k autour de la fenêtre ; grep pour link et events driver.
- Compteurs hôte : ethtool -S pour chaque esclave ; ip -s link pour les drops.
- Vérité config hôte : /sys/class/net/bond0/bonding/* plus ip -d link show.
- Capture LACPDU : 60 secondes sur chaque esclave pendant la fenêtre de flap.
- Demande au switch : demander état port-channel, codes raison par membre, partner ID/key, et compteurs par port pour les mêmes timestamps.
- Corréler : les timestamps correspondent-ils ? la même jambe se comporte-t-elle mal de façon consistante ?
- Isoler : déplacer un câble/optique/port à la fois si le physique est suspect ; retester.
- Décider et corriger : choisir une hypothèse et valider par changement + mesure.
Étape par étape : isolement physique sans empirer les choses
- Identifier la « jambe mauvaise » par churn/compteurs/capture (eno1 vs eno2).
- Swappez uniquement le câble/DAC sur cette jambe ; ne changez pas les deux en même temps.
- Re-vérifier les compteurs CRC/FCS en baseline, puis après 10 minutes sous charge.
- Si toujours mauvais, swappez l’optique, puis changez de port switch, puis migrez vers une autre line card si possible.
- Documentez chaque changement avec compteurs avant/après. Cela évite le folklore « ça s’est amélioré tout seul ».
Étape par étape : audit de symétrie de configuration (hôte + switch)
- Hôte : les deux esclaves ont le même MTU, mêmes offloads, même speed/duplex/autoneg, même classe driver/firmware.
- Hôte : mode bond 802.3ad, ad_select stable, miimon sensé, et lacp_rate correspondant à l’attente switch.
- Switch : les deux ports membres ont la même liste VLAN, MTU, mode LACP, lacp_rate, et sont dans le même port-channel.
- MLAG : les deux switches ont des configs port-channel identiques et le peer-link est sain ; pas d’incohérences « orphelines ».
FAQ
1) Debian 13 est-il spécial ici, ou est-ce juste « Linux bonding » ?
Principalement du bonding Linux. Debian 13 compte car les versions kernel/driver changent des comportements, et systemd-networkd vs ifupdown change comment la dérive de configuration survient.
2) Quel est le meilleur fichier unique à regarder pour les problèmes LACP sur l’hôte ?
/proc/net/bonding/bond0. Il montre le churn, l’identité du partenaire, les clés, les numéros de port et le compteur de link failure. C’est le plus proche d’un enregistreur de boîte noire.
3) Si le switch dit que le port-channel est up, peut-il encore être cassé ?
Oui. « Up » peut signifier « un membre est agrégé ». Vous pouvez toujours avoir une jambe suspendue, churnante ou en erreur. Demandez l’état par membre et les raisons.
4) Dois-je utiliser LACP fast ou slow ?
Fast si vous pouvez garantir que le trafic de contrôle n’est pas droppé et que les hôtes ne sont pas affamés ; slow si vous voulez de la tolérance. Si vous utilisez fast, mesurez la gigue et la perte, pas seulement l’état du lien.
5) Comment prouver que l’hôte envoie des LACPDUs ?
tcpdump sur l’interface esclave avec EtherType 0x8809, vérifiant que la source MAC correspond au MAC du bond et que la cadence correspond à lacp_rate.
6) Comment prouver que le switch renvoie des LACPDUs ?
Même capture, mais cherchez des trames source provenant du MAC LACP du switch. Si vous voyez l’hôte en sortie mais pas d’entrants sur une jambe, c’est une preuve solide.
7) Un mauvais câble peut-il provoquer des flaps LACP sans événements link down ?
Oui. Vous pouvez obtenir des erreurs et micro-interruptions qui ne tombent pas le carrier assez longtemps pour logguer link down, mais qui perturbent l’échange de LACPDU et la qualité du trafic.
8) La politique de hashing cause-t-elle des flaps ?
Non, la politique de hashing provoque généralement des bizarreries de performance, pas du churn de négociation LACP. Mais ces bizarreries de performance sont souvent prises à tort pour « le bond flappe ». Vérifiez /proc/net/bonding et les compteurs de churn.
9) Et si un seul hôte dans l’armoire flappe et les autres sont ok ?
Sospettez des différences firmware/driver côté hôte, un mauvais port NIC, ou un câble/optique défectueux. Ensuite suspectez un port switch unique. Utilisez compteurs et isolement de la « jambe mauvaise ».
10) Et si plusieurs hôtes flappent sur la même paire de switches en même temps ?
Sospettez d’abord le switch : peer-link MLAG, congestion control-plane, template mal appliqué, ou bug logiciel. Demandez les logs switch autour des mêmes timestamps et comparez le comportement partner/key.
Conclusion : prochaines étapes pratiques
Quand des bonds LACP flappent, vous gagnez en étant méthodique plutôt que bruyant. Commencez par la classification la plus simple : carrier flapping vs churn LACP avec carrier stable. Ensuite, collectez les trois types de preuves qui tiennent lors d’un débat inter-équipes : logs kernel, compteurs, et captures de paquets.
Prochaines étapes qui terminent généralement la discussion :
- Capturer 60 secondes de LACPDUs sur chaque esclave pendant un flap.
- Exporter /proc/net/bonding/bond0 avant/pendant/après et corréler les timestamps avec les logs switch.
- Comparer CRC/FCS et drops sur les ports hôte et switch pour isoler le segment défaillant.
- Forcer un down/up contrôlé sur un esclave en fenêtre de maintenance pour vérifier le comportement déterministe de l’hôte.
- Si MLAG est en jeu, exiger des preuves de santé du peer-link et de symétrie de configuration, pas des assurances.
Faites cela, et vous cesserez de « dépanner » et commencerez à prouver. En production, c’est la différence entre corriger le problème et simplement le déplacer à la semaine suivante.