L’agrégation de liens (Link-Aggregation, LACP) est un moyen fondamental pour obtenir de la redondance et un débit agrégé. Le mot-clé principal Link-Aggregation (LACP) est délibérément placé en tête : LACP regroupe plusieurs liaisons Ethernet physiques en une liaison logique (LAG, Link Aggregation Group) et négocie cela via des trames LACPDU. En pratique, les problèmes proviennent moins du protocole lui‑même que de réglages périphériques incohérents : marquage VLAN, MTU, hashing, timers LACP, configurations multi-châssis (MLAG/vPC) ou protection contre les boucles. Ce guide présente une séquence de vérification compacte, des scénarios d’erreur typiques, des tests concrets et une stratégie de repli pragmatique pour l’exploitation en production.
Ce que négocie LACP — et ce que vous devez régler séparément
LACP (IEEE 802.3ad / 802.1AX) permet à deux côtés de reconnaître des ports membres comme faisant partie d’une agrégation et de convenir des liaisons physiques actives. LACP gère l’affectation des membres, mais pas le marquage VLAN, la MTU ni les décisions de forwarding (hashing). Cette séparation est centrale : un LAG peut être formellement « up » alors que certains VLANs, de gros transferts ou des sessions de pare‑feu échouent.
Décisions avant la configuration
Topologie : single‑chassis vs. multi‑chassis
Un LAG single‑chassis termine sur un seul switch/stack. Un LAG multi‑chassis (MLAG/vPC) répartit les membres sur deux switches physiques, augmente la disponibilité mais crée une domaine d’erreur supplémentaire : Peer‑Link, synchronisation d’état (state‑sync) et protection contre le split‑brain. De nombreux blocages apparents de LACP sont en réalité des problèmes de synchronisation MLAG.
Mode et timers
Choisissez le mode LACP (active/passive) de manière consciente. Active/Active est généralement plus fiable dans des environnements hétérogènes, car les deux côtés envoient des LACPDUs. Fixez le taux LACP (fast/slow) des deux côtés : des valeurs de timer différentes peuvent provoquer des re‑sélections inattendues.
Stratégie d’erreur : Min‑Links, Fallback, Degradation
Définissez Min‑Links (nombre minimal de membres actifs) pour éviter qu’un seul lien ne porte à lui seul le trafic comme s’il s’agissait d’un agrégat. Évitez dans la mesure du possible le basculement automatique vers des port‑channels statiques ; cela augmente les risques de boucle si les extrémités ne sont pas configurées de manière identique. Pour MLAG, prévoyez des règles de comportement claires en cas d’incident sur le Peer‑Link.
Pièges typiques — causes pratiques
Incohérences VLAN / trunk
Le plus souvent, LACP ne pose pas de problème lors de la négociation, mais échoue à cause de VLAN manquants ou de paramètres trunk/access divergents sur les ports membres. Symptôme : le LAG est vert, mais certains VLANs ou services sont inaccessibles. Vérifiez impérativement la configuration trunk sur l’interface LAG, et non pas sur des ports individuels.
Inadéquation MTU et Jumbo‑Frames
La MTU est dépendante du chemin. Si un lien ou un point intermédiaire a une MTU plus petite, le chemin fragmentera ou abandonnera les paquets. Conséquence typique : les petits paquets passent, les gros transferts échouent. PMTUD échoue si les messages ICMP « Fragmentation needed » sont filtrés.
Le hashing ne correspond pas à la charge
LACP répartit les flux via un hashing (p. ex. champs L2/L3/L4). Un « elephant flow » peut saturer un seul membre alors que les autres restent libres. Cela devient souvent critique en production avec des pare‑feu, des flux de sauvegarde ou la réplication de stockage.
Problèmes physiques et oscillations de lien
Transceivers défectueux, rupture de fibre, problèmes de DAC, mismatch d’autonégociation ou mécanismes d’économie d’énergie entraînent des flaps et des renégociations constantes. LACP peut rester en état « up », mais STP, l’apprentissage MAC et le forwarding subissent une fluctuation permanente.
STP et protection contre les boucles
STP considère une LAG correctement formée comme un port logique. En cas de mismatch (p. ex. statique vs. LACP) STP peut voir et bloquer des ports membres individuellement — cela provoque des impasses apparentes. Les fonctions de protection contre les boucles (BPDU Guard, UDLD) peuvent mettre des ports en err-disable et ainsi paralyser partiellement l’agrégat.
Schémas de type deadlock et causes techniques
Deadlock n’est pas un état LACP, mais décrit des situations opérationnelles où mécanismes de contrôle et de protection se bloquent mutuellement. Quatre schémas récurrents :
- LAG up, pas de trafic attendu : VLAN/MTU/algorithme de hashing ou défaut de lien unidirectionnel.
- Interruptions périodiques : mismatch de timers (fast/slow) ou rythmes de flapping.
- MAC‑Flapping / problèmes ARP : boucle, MLAG split‑brain ou incompatibilité Host‑Teaming.
- Membre sélectionné, mais forwarding bloqué : STP/Loop‑Protect ou UDLD en err‑disable.
Parcours de vérification lors d’un incident — étapes rapides et reproductibles
Procédez de manière structurée : des vérifications de configuration simples vers des tests Layer‑1/2.
1) Délimiter : qu’est‑ce qui est exactement affecté ?
Questions : un seul VLAN ? seulement des gros transferts ? un seul sens de communication ? un seul membre ? des changements récents (firmware, câbles, configuration) ?
2) Vérifier l’état LACP des deux côtés
Comparez les Actor/Partner‑IDs, la liste des membres, l’Aggregator‑ID et si les ports sont en état collecting/distributing.
# Exemple : Linux état du bonding et stats du lien
cat /proc/net/bonding/bond0
for i in eth0 eth1; do
echo "=== $i ===";
ethtool $i;
ethtool -S $i | egrep -i "err|drop|crc|discard|timeout" || true;
done
lldpcli show neighbors
3) Vérifier la consistance VLAN/Trunk
Vérifiez les tags par capture sur un port membre et testez la connectivité par VLAN. Si les tags sont absents ou n’apparaissent que sur certains membres, la configuration du switch est incohérente.
# Afficher les paquets avec tag VLAN
tcpdump -eni eth0 -c 50 vlan
# Exemple : vérifier le sous-interface VLAN
ip -d link show bond0.100
4) Tester le chemin MTU
Effectuez des ping DF pour vérifier le Path MTU. Attention : le filtrage ICMP peut perturber le PMTUD.
# IPv4 : tests DF
ping -M do -s 1472 -c 3 198.51.100.10 # MTU 1500
ping -M do -s 8972 -c 3 198.51.100.10 # MTU 9000 (Jumbo)
5) Compteurs d’erreurs et erreurs unidirectionnelles
Les CRC errors, corrections FEC ou input errors indiquent un problème Layer‑1/2. UDLD peut détecter des erreurs unidirectionnelles, mais ne l’activez que si le comportement a été documenté dans la durée.
6) Vérifier STP / protections contre les boucles
Les vues STP correspondent‑elles ? La LAG est‑elle traitée comme une interface ou voyez‑vous les membres individuels dans le bridge ? Les événements BPDU Guard ou les Topology Changes se corrèlent souvent avec des problèmes LACP.
7) MLAG/vPC : le peer‑link en tant que domaine d’erreur propre
Vérifiez la stabilité du peer‑link, la liste d’autorisation VLAN sur le peer‑link, le chemin de keepalive et les consistency checks. De nombreux mécanismes de protection désactivent des ports si le peer‑link rencontre des problèmes.
Expériences ciblées en production (falsifier rapidement les hypothèses)
Désactiver les liens membres un par un
Désactivez temporairement des membres individuellement pour vérifier si le problème disparaît ou se déplace. Si oui, le chemin ou l’équipement correspondant à ce lien est la cause.
Expériences MTU et PMTUD
Testez de gros transferts avec des ping DF et des transferts de fichiers contrôlés. Si les messages de fragmentation sont absents (à cause d’un filtrage ICMP), vous ne détecterez les problèmes PMTUD qu’en observant les retransmissions TCP.
Provoquer/analyser délibérément le MAC-flapping
Déterminez si des hôtes utilisent des modes de teaming incorrects. Sur Linux montre /proc/net/bonding le mode ; les divergences entre Switch-LACP et le teaming côté hôte sont des sources d’erreurs classiques.
Exemples de configuration concrets et commandes de vérification
Les exemples suivants aident à repérer les formes de configuration typiques et à les vérifier de manière fiable. Adaptez la syntaxe à votre vendor et à votre version de l’OS.
Cisco IOS / IOS-XE : Port-Channel avec LACP
interface Port-channel10
description LAG to Firewall-Cluster
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20,30
ip mtu 9000
!
interface GigabitEthernet1/0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
!
interface GigabitEthernet1/0/2
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
Important : les paramètres de trunk et de MTU s’appliquent au Port-Channel. Les membres individuels ne doivent pas avoir des paramètres VLAN ou MTU différents.
Linux Bonding (active-backup vs. 802.3ad)
# /etc/network/interfaces (Debian-Beispiel)
auto bond0
iface bond0 inet static
address 10.0.0.10/24
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1
mtu 9000
Remarque : bond-lacp-rate fast correspond au timer LACP rapide. Utilisez le même réglage sur le switch.
Procédures pratiques et dépannage spécifiques aux pare-feu
Les pare-feu sont particulièrement critiques, car ils maintiennent des sessions stateful. Une perte de paquet isolée ou un chemin asymétrique peut interrompre des sessions.
1) Vérifier l’état des sessions et du cluster
Contrôlez les compteurs de sessions, les drops et les erreurs de synchronisation de cluster sur le pare-feu. Pour les clusters, vérifiez les erreurs de réplication ou de heartbeat — elles sont souvent corrélées à des problèmes LACP.
2) Vérifications de routage asymétrique
Assurez-vous que le chemin de retour et le hashing d’ingress sont cohérents. En cas d’absence de symétrie, effectuez des traces de paquets (tcpdump) des deux côtés et comparez les en-têtes TCP et IP.
# Beispiel: Paket-Trace an Firewall-Interface
tcpdump -ni eth0 -w /tmp/fw_eth0.pcap 'tcp and host 10.0.0.5'
# parallel auf Gegenstelle
tcpdump -ni eth1 -w /tmp/switch_eth1.pcap 'tcp and host 10.0.0.5'
3) Vérifier la politique PMTUD
Les pare-feu ne doivent pas bloquer l’ICMP de manière générale. Vérifiez les règles de filtrage ICMP et activez éventuellement temporairement les logs pour ICMP Fragmentation Needed.
4) Politique de hashing pour les services stateful
Pour des charges VPN, IPSec ou de Statefull-Proxy, un hash L3/L4 tenant compte des ports source et destination est recommandé. Évitez le hashing purement L2 pour de nombreuses sessions provenant de la même plage d’IP.
Runbook opérationnel : playbook d’incident pour les pannes LACP
Un runbook concis augmente les chances d’une reprise rapide. Important : responsabilités claires, étapes communicables, garantir la collecte de la télémétrie.
Étapes d’urgence (version courte)
- Confirmer l’alarme et documenter les conséquences (VLANs, services affectés).
- Exporter un snapshot des configurations et des logs pertinents (Switch, Firewall, Host).
- Désactiver et observer les membres un par un de manière contrôlée (max 30s entre les modifications).
- En cas d’indication claire de défaillance d’un membre : mettre le port hors service, activer le LAN/Transceiver de secours.
- Si MLAG est affecté : vérifier le Peer-Link, isoler temporairement le peer si nécessaire et rétablir un fonctionnement en Single-Chassis.
Konfig-/Log-Export-Beispiele
# Switch: Konfiguration sichern (Beispiel SSH-Session)
show running-config | redirect flash:running-config-$(date +%F).txt
show logging | redirect flash:logs-$(date +%F).txt
# Firewall: Sessions und Cluster-Status
show session summary
show cluster status
Monitoring und präventive Checks
Automatisez les contrôles suivants pour obtenir des alertes précoces :
- Nombre de membres par LAG et modifications inattendues
- Changements d’état LACP (Partner-ID-Wechsel, suspended)
- Taux d’erreur PMTU et messages ICMP de fragmentation
- Taux de MAC‑flapping par VLAN
- Latence du Peer-Link, pertes et erreurs de Keepalive (bei MLAG/vPC)
Les métriques peuvent être collectées via SNMP, Telemetry (gNMI/streaming) ou via syslog/collectd. Établissez des baselines et alertez sur les écarts, pas seulement sur des seuils.
Best Practices zusammengefasst
- Symétrie de configuration : Trunk/VLAN/MTU/Speed/Auto-Neg identiques des deux côtés.
- Timing : harmonisez la LACP‑Rate et les timeouts sur les deux côtés.
- Min-Links : définissez un nombre minimum de liens et testez les scénarios de dégradation.
- MLAG : surveillez le Peer-Link & le Keepalive comme des services distincts.
- Pare-feu : surveillez activement la PMTUD et la santé des sessions, ajustez le hashing pour les charges de travail stateful.
- Documentation : définissez les Runbooks, les sauvegardes de configuration, les scénarios de test et le processus RCA.
Abschließendes Fazit
La stabilité de l’agrégation de liens repose sur la cohérence : mêmes paramètres de port, conception VLAN et MTU homogène, politique de hashing appropriée et, en multi‑châssis, un Peer‑Link sain avec une stratégie claire de Split‑Brain. Les symptômes proches d’un deadlock sont généralement la conséquence de plusieurs mécanismes de protection qui se superposent (LACP, STP, Loop‑Protection, MLAG/Keepalive). Avec une séquence de vérification claire, des expérimentations précises (désactiver un membre, tester le MTU, corréler les événements de flap/MAC) et une stratégie de repli pragmatique, vous réduisez les temps d’arrêt et posez les bases d’une exploitation résiliente.
Link-Aggregation (LACP) in Betrieb, Automatisierung und System‑Integration
Outre la simple configuration réseau, l’exploitation détermine la fiabilité : comment les changements LACP sont-ils tracés, comment la supervision réagit-elle et comment la couche réseau s’intègre‑t‑elle à vos solutions numériques d’entreprise et à la CMDB ? Ce sont souvent les principaux risques — non pas parce que LACP échoue, mais parce que les processus, la télémétrie et les particularités des vendors ne sont pas automatiquement rapprochés.
Aspects opérationnels essentiels et recommandations :
- Détection automatisée de la dérive de configuration : exportez en continu les configurations LAG et de port vers un dépôt de versions. Ainsi, un rollback peut être appliqué rapidement et les modifications sont auditées.
- Documenter les particularités des vendors : les algorithmes de hashing basés sur ASIC, le CPU‑offload ou des timers LACP par défaut différents (Cisco vs. Arista vs. Broadcom‑Silicon) entraînent des comportements hétérogènes. Enregistrez ces écarts dans l’inventaire et vérifiez la compatibilité des firmwares avant les rollouts.
- Protection du plan de contrôle : de nombreux LACP‑flaps génèrent une forte charge CPU sur les contrôleurs de switch. Des limites, des rate‑limits pour les LACPDU et une alerte ciblée évitent la dégénérescence du plan de contrôle.
- Interfaces d’intégration : Envoyez les changements d’état LACP vers votre solution de journalisation/télémétrie (gNMI, SNMP‑Traps, syslog). Associez les alarmes au système de ticketing et à votre inventaire, afin que les modifications de configuration et les pièces de rechange physiques (transceivers) soient automatiquement rattachées.
Contrôle d’automatisation pratique : une boucle SSH simple recueille les IDs de partenaires LACP de plusieurs équipements et met en évidence les écarts. Adaptez les commandes spécifiques au fournisseur à votre CLI.
#!/usr/bin/env bash
# hosts.txt enthält eine Zeile pro Switch
while read host; do
echo "== $host ==";
ssh admin@${host} "show lacp neighbor || show etherchannel summary" 2>/dev/null | sed -n '1,120p'
done < hosts.txt
Utilisez ce résultat comme base pour un diff automatisé par rapport au dernier snapshot de configuration persisté. Si une divergence est détectée, déclenchez un Canary‑Test : désactivation temporaire d’un membre dans un VLAN de laboratoire, vérification automatique de l’état et, en cas de succès, déploiement contrôlé.
Enfin : associez les événements de monitoring à vos processus opérationnels. Un changement LACP ne devrait pas seulement générer une alerte, mais fournir automatiquement le contexte (letzte Config‑Commit, Firmware‑Version, clusters de pare‑feu associés). Cela réduit le MTTR et évite que des problèmes d’infrastructure entraînent des perturbations de vos logiciels métier et de vos solutions logicielles proches des processus.