Link-Aggregation (LACP) ist ein grundlegendes Betriebsmittel, um Redundanz und aggregierten Durchsatz zu erreichen. Das Fokus-Keyword Link-Aggregation (LACP) steht hier bewusst am Anfang: LACP bündelt mehrere physische Ethernet-Links zu einer logischen Verbindung (LAG, Link Aggregation Group) und verhandelt dafür über LACPDU-Frames. In der Praxis entstehen Probleme weniger durch das Protokoll selbst als durch inkonsistente Nebeneinstellungen: VLAN-Tagging, MTU, Hashing, LACP-Timer, Multi-Chassis-Setups (MLAG/vPC) oder Loop‑Protection. Dieser Leitfaden zeigt eine kompakte Prüfsequenz, typische Fehlerbilder, konkrete Tests und eine pragmatische Rückfallstrategie für den produktiven Betrieb.
Was LACP aushandelt — und was Sie separat klären müssen
LACP (IEEE 802.3ad / 802.1AX) sorgt dafür, dass zwei Seiten Mitgliedsports als Teil einer Aggregation erkennen und vereinbaren, welche physischen Links aktiv werden. LACP regelt die Member‑Zuweisung, nicht aber VLAN-Tagging, MTU oder die Forwarding-Entscheidungen (Hashing). Diese Trennung ist zentral: Ein LAG kann formal „up“ sein, während bestimmte VLANs, große Transfers oder Firewall-Sessions scheitern.
Entscheidungen vor der Konfiguration
Topologie: Single-Chassis vs. Multi-Chassis
Single-Chassis-LAG terminiert auf einem Switch/Stack. Multi-Chassis-LAG (MLAG/vPC) verteilt Member auf zwei physischen Switches, erhöht Verfügbarkeit, erzeugt aber eine zusätzliche Fehlerdomäne: Peer-Link, State-Sync und Split-Brain-Schutz. Viele scheinbare LACP-Deadlocks sind in Wahrheit MLAG-Synchronisationsprobleme.
Modus und Timer
Wählen Sie LACP-Modus (active/passive) bewusst. Active/Active ist in heterogenen Umgebungen meist zuverlässiger, weil beide Seiten LACPDUs senden. Legen Sie LACP-Rate (fast/slow) beidseitig fest: Unterschiedliche Timerwerte können zu unerwarteten Re‑Selectionen führen.
Fehlerstrategie: Min-Links, Fallback, Degradation
Definieren Sie Min-Links (Mindestanzahl aktiver Member), um zu vermeiden, dass eine einzelne Leitung als „Bündel“ allein den Verkehr trägt. Vermeiden Sie nach Möglichkeit automatischen Fallback auf statische Port-Channels; das erhöht Loop-Risiken, wenn Gegenstellen nicht identisch konfiguriert sind. Für MLAG planen Sie klare Verhaltensregeln bei Peer-Link-Störungen.
Typische Stolperfallen — praktische Ursachen
VLAN-/Trunk-Inkonsistenz
Am häufigsten scheitert LACP nicht an der Aushandlung, sondern an fehlenden VLANs oder unterschiedlichen Trunk-/Access-Settings auf Mitgliedsports. Symptom: LAG ist grün, aber einzelne VLANs oder Services sind nicht erreichbar. Prüfen Sie Trunk-Konfiguration unbedingt auf dem LAG-Interface, nicht an einzelnen Ports.
MTU- und Jumbo-Frame-Mismatch
MTU ist pfadbezogen. Wenn ein Link oder ein Zwischenpunkt eine kleinere MTU hat, fragmentiert oder droppt der Pfad. Typische Folge: Kleine Pakete funktionieren, große Transfers brechen. PMTUD scheitert, wenn ICMP „Fragmentation needed“ gefiltert wird.
Hashing passt nicht zur Last
LACP verteilt Flows via Hashing (z. B. L2/L3/L4-Felder). Ein „Elefanten-Flow“ kann einen einzelnen Member saturieren, während andere frei bleiben. Das ist oft betrieblich relevant bei Firewalls, Backup‑Streams oder Storage‑Replikation.
Physische Probleme und Link Flapping
Fehlerhafte Transceiver, Faserbruch, DAC-Probleme, Autoneg-Mismatch oder Energiesparmechanismen führen zu Flaps und ständigen Neuverhandlungen. LACP bleibt zwar im Up‑Zustand, doch STP, MAC‑Learning und Forwarding geraten in ständige Fluktuation.
STP und Loop‑Protection
STP betrachtet eine korrekt gebildete LAG als einen logischen Port. Bei Mismatch (z. B. statisch vs. LACP) kann STP Mitgliedsports einzeln sehen und blockieren – das verursacht scheinbare Deadlocks. Loop‑Protection‑Features (BPDU Guard, UDLD) können Ports err-disable setzen und so das Bündel partiellement lahmlegen.
Deadlock-ähnliche Muster und technische Ursachen
Deadlock ist kein LACP‑State, aber beschreibt betriebliche Situationen, in denen Steuer- und Schutzmechanismen sich gegenseitig blockieren. Vier wiederkehrende Muster:
- LAG up, kein/gewünschter Traffic: VLAN/MTU/Hashing oder unidirektionaler Link-Defekt.
- Periodische Aussetzer: Timer-Mismatch (fast/slow) oder Flapping‑Rhythmen.
- MAC‑Flapping / ARP‑Probleme: Loop, MLAG‑Split‑Brain oder Host‑Teaming‑Mismatch.
- Member selected, aber Forwarding blockiert: STP/Loop‑Protect oder UDLD err‑disable.
Prüfpfad im Incident — schnelle, reproduzierbare Schritte
Gehen Sie strukturiert vor: von einfachen Konfigchecks zu Layer‑1/2‑Tests.
1) Eingrenzen: Was genau ist betroffen?
Fragen: Nur ein VLAN? Nur große Transfers? Nur ein Richtungspfad? Nur ein Member? Gab es kürzlich Änderungen (Firmware, Kabel, Konfiguration)?
2) LACP-Status beidseitig prüfen
Vergleichen Sie Actor/Partner-IDs, Memberliste, Aggregator-ID und ob Ports im Zustand collecting/distributing sind.
# Beispiel: Linux Bonding-Status und Link-Stats
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) VLAN/Trunk-Konsistenz prüfen
Prüfen Sie Tags per Capture an einem Mitgliedsport und testen Sie Reachability je VLAN. Fehlen Tags oder erscheinen nur auf einzelnen Membern, ist die Switch‑Konfiguration inkonsistent.
# VLAN-Tag-Paket sichtbar machen
tcpdump -eni eth0 -c 50 vlan
# Beispiel: VLAN-Subinterface prüfen
ip -d link show bond0.100
4) MTU-Pfad testen
Führen Sie DF‑Pings durch, um Pfad‑MTU zu verifizieren. Beachten: ICMP-Filtering kann PMTUD stören.
# IPv4: DF-Tests
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) Fehlerzähler und unidirektionale Fehler
CRC-Errors, FEC-Korrekturen oder Input-Errors weisen auf Layer‑1/2 hin. UDLD kann unidirektionale Fehler erkennen, aber aktiviert es nur, wenn Verhalten im Laufe dokumentiert ist.
6) STP/Loop-Schutz prüfen
Stimmen STP-Ansichten? Wird die LAG als Schnittstelle behandelt oder sehen Sie einzelne Member in der Bridge? BPDU Guard-Events oder Topology Changes korrelieren oft mit LACP-Problemen.
7) MLAG/vPC: Peer-Link als eigene Fehlerdomäne
Überprüfen Sie Peer-Link-Stabilität, VLAN-Allow-List auf dem Peer-Link, Keepalive-Path und Consistency-Checks. Viele Schutzmechanismen deaktivieren Ports, wenn der Peer-Link Probleme hat.
Gezielte Experimente im Betrieb (Hypothesen schnell falsifizieren)
Mitgliedslink nacheinander deaktivieren
Deaktivieren Sie temporär einzelne Member, um zu sehen, ob das Problem verschwindet oder wandert. Wenn ja, ist der Pfad oder das Gerät für diesen Link die Ursache.
MTU- und PMTUD-Experimente
Testen Sie große Transfers mit DF-Pings und kontrollierten Dateiübertragungen. Wenn Fragmentation-Nachrichten fehlen (wegen ICMP-Filter), erkennen Sie PMTUD-Probleme erst durch Beobachtung von TCP‑Retransmits.
MAC-Flapping gezielt provozieren/analysieren
Ermitteln Sie, ob Hosts falsche Teaming-Modi verwenden. Auf Linux zeigt /proc/net/bonding den Modus; mismatches zwischen Switch-LACP und Host-Teaming sind klassische Fehlerquellen.
Konkrete Konfigurationsbeispiele und Prüfkommandos
Die folgenden Beispiele helfen, typische Konfigurationsformen zu erkennen und valide zu prüfen. Passen Sie Syntax an Ihren Vendor und Ihre OS-Version an.
Cisco IOS / IOS-XE: Port-Channel mit 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
Wichtig: Die Trunk- und MTU-Einstellungen sind auf dem Port‑Channel wirksam. Einzelne Member sollten nicht abweichende VLAN- oder MTU-Settings haben.
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
Beachten: bond-lacp-rate fast entspricht dem schnellen LACP-Timer. Verwenden Sie die gleiche Einstellung auf dem Switch.
Firewall-spezifische How-tos und Troubleshooting
Firewalls sind besonders kritisch, weil sie Stateful-Sessions halten. Ein einzelner Paketverlust oder asymmetrischer Pfad kann Sessions abbrechen.
1) Session- und Cluster-Health prüfen
Kontrollieren Sie Session-Zähler, Drops und Cluster-Sync-Errors auf der Firewall. Bei Clustern prüfen Sie Replikations- oder Heartbeat-Fehler—diese korrelieren oft mit LACP-Problemen.
2) Asymmetrische Routing-Checks
Stellen Sie sicher, dass Return-Path und Ingress-Hashing konsistent sind. Bei fehlender Symmetrie führen Sie Paket-Traces (tcpdump) an beiden Seiten durch und vergleichen TCP- und IP-Header.
# 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) PMTUD-Policy prüfen
Firewalls dürfen ICMP nicht pauschal blockieren. Prüfen Sie ICMP-Filterregeln und aktivieren Sie gegebenenfalls temporär Logs für ICMP Frag Needed.
4) Hashing-Policy für Stateful-Dienste
Für VPN-, IPSec- oder Statefull-Proxy-Workloads empfiehlt sich ein L3/L4-Hash, der Quell- und Zielport berücksichtigt. Vermeiden Sie rein L2-basiertes Hashing bei vielen Sessions aus gleicher IP-Range.
Operational Runbook: Incident Playbook für LACP-Ausfälle
Ein schlankes Runbook erhöht die Chance auf schnelle Wiederherstellung. Wichtig: klare Verantwortlichkeiten, kommunizierbare Schritte, Telemetrie sichern.
Notfall-Schritte (Kurzversion)
- Alarm bestätigen und Konsequenzen dokumentieren (betroffene VLANs, Services).
- Snapshot der Konfigurationen und relevanter Logs exportieren (Switch, Firewall, Host).
- Ein Member nach dem anderen kontrolliert deaktivieren und beobachten (max 30s zwischen Änderungen).
- Bei klarer Member-Defekt‑Indikation: Port stilllegen, Ersatz-LAN/Transceiver aktivieren.
- Wenn MLAG betroffen: Peer-Link prüfen, ggf. Peer temporär isolieren und Single-Chassis-Betrieb herstellen.
- Nach Stabilisierung: RCA (Root Cause Analysis) innerhalb 24–48 Stunden und Update der Runbooks.
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
Automatisieren Sie folgende Checks, um frühe Warnungen zu erhalten:
- Member‑Count pro LAG und unerwartete Änderungen
- LACP-State-Changes (Partner-ID-Wechsel, suspended)
- PMTU-Fehler-Rate und ICMP Fragmentation-Nachrichten
- MAC‑Flapping-Rate pro VLAN
- Peer-Link-Latenz, Drops und Keepalive-Errors (bei MLAG/vPC)
Metriken können per SNMP, Telemetry (gNMI/streaming) oder via syslog/collectd eingesammelt werden. Stellen Sie Baselines her und alarmieren Sie ab Abweichungen, nicht nur bei Grenzwerten.
Best Practices zusammengefasst
- Konfigurationssymmetrie: Trunk/VLAN/MTU/Speed/Auto-Neg beidseitig identisch.
- Timing: LACP-Rate und Timeouts auf beiden Seiten abstimmen.
- Min-Links: Definieren Sie Mindestanzahl und testen Sie Degradation-Szenarien.
- MLAG: Peer-Link & Keepalive als eigene Services überwachen.
- Firewall: PMTUD und Session-Health aktiv überwachen, Hashing für Statefull-Workloads anpassen.
- Dokumentation: Runbooks, Konfig-Backups, Testszenarien und RCA-Prozess festlegen.
Abschließendes Fazit
Stabile Link-Aggregation entsteht durch Konsistenz: gleiche Port-Parameter, einheitliches VLAN‑ und MTU‑Design, passende Hashing‑Policy und bei Multi‑Chassis ein gesunder Peer‑Link mit klarer Split‑Brain‑Strategie. Deadlock‑ähnliche Symptome sind meist Folge mehrerer Schutzmechanismen, die sich überlagern (LACP, STP, Loop‑Protection, MLAG/Keepalive). Mit einer klaren Prüfreihenfolge, präzisen Experimenten (Mitglied deaktivieren, MTU testen, Flap‑/MAC‑Events korrelieren) und einer pragmatischen Rückfallstrategie reduzieren Sie Ausfallzeiten und legen die Grundlage für belastbaren Betrieb.
Link-Aggregation (LACP) in Betrieb, Automatisierung und System‑Integration
Neben der reinen Netzkonfiguration entscheidet der Betrieb über Zuverlässigkeit: Wie werden LACP‑Änderungen nachverfolgt, wie reagiert das Monitoring und wie integriert sich die Netzebene in Ihre digitalen Unternehmenslösungen und CMDB? Hier liegen oft die größten Risiken — nicht, weil LACP versagt, sondern weil Prozesse, Telemetrie und Vendor‑Eigenheiten nicht automatisiert abgeglichen werden.
Wesentliche Betriebsaspekte und Empfehlungen:
- Config‑Drift automatisiert erkennen: Exportieren Sie laufend die LAG‑ und Port‑Configs in ein Versions-Repository. So lässt sich ein Rollback zeitnah einspielen und Änderungen sind auditierbar.
- Vendor‑Quirks dokumentieren: ASIC‑basierte Hash‑Algorithmen, CPU‑Offload, oder unterschiedliche Default‑LACP‑Timers (Cisco vs. Arista vs. Broadcom‑Silicon) führen zu uneinheitlichem Verhalten. Halten Sie diese Abweichungen im Inventar fest und prüfen Sie Firmware‑Kompatibilität vor Rollouts.
- Control‑Plane‑Schutz: Viele LACP‑Flaps erzeugen hohe CPU‑Last auf Switch‑Controllern. Limits, Rate‑Limits für LACPDU und gezielte Alarmierung verhindern Kontroll‑Plane‑Degeneration.
- Integrationsschnittstellen: Senden Sie LACP‑State‑Änderungen in Ihr Logging/Telemetry (gNMI, SNMP‑Traps, syslog). Verknüpfen Sie Alarme mit Ticketing und Ihrem Inventar, damit Konfigänderungen und physische Ersatzteile (Transceiver) automatisch zugeordnet werden.
Praktischer Automations‑Check: Ein einfacher SSH‑Loop sammelt LACP‑Partner‑IDs von mehreren Geräten und zeigt Abweichungen. Passen Sie Vendor‑Befehle an Ihre CLI an.
#!/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
Nutzen Sie dieses Ergebnis als Basis für ein automatisiertes Diff gegen das zuletzt persistierte Config‑Snapshot. Wird eine Abweichung entdeckt, lösen Sie einen Canary‑Test aus: temporäres Deaktivieren eines Members in einem Labor‑VLAN, automatischer Health‑Check und bei Erfolg kontrolliertes Rollout.
Schließlich: Verknüpfen Sie Monitoring‑Events mit Ihren Betriebsprozessen. Ein LACP‑Change sollte nicht nur eine Alarmmeldung erzeugen, sondern automatisch Kontext liefern (letzte Config‑Commit, Firmware‑Version, zugeordnete Firewall‑Cluster). So reduzieren Sie MTTR und vermeiden, dass Infrastrukturprobleme zu Störungen Ihrer Business‑Software und prozessnahen Softwarelösungen führen.