EtherChannel/LACP Troubleshooting: Bundles, Hashing und LAG Split

EtherChannel/LACP Troubleshooting ist eine der wichtigsten Fähigkeiten im Betrieb moderner LAN- und Data-Center-Netze, weil Link Aggregation (LAG) gleichzeitig Verfügbarkeit und Kapazität erhöhen soll – aber im Fehlerfall extrem „komische“ Symptome erzeugt. Ein Bundle, das „up“ aussieht, kann trotzdem einzelne VLANs verlieren, MAC-Flapping verursachen, sporadische Paketverluste erzeugen oder nur einen Teil der Flows massiv verlangsamen. Häufig ist dann nicht „das Netzwerk langsam“, sondern der Port-Channel inkonsistent: LACP verhandelt unterschiedlich, ein Member hat abweichende Allowed VLANs, MTU oder Speed, Hashing verteilt Flows ungleich, oder es entsteht ein LAG Split (die beiden Seiten haben unterschiedliche Vorstellungen, welche Links zum Bundle gehören). Besonders tückisch ist: Viele Tools zeigen den Port-Channel als logisches Interface, während der Fehler in einem einzelnen physischen Member steckt. In diesem Artikel lernen Sie ein systematisches Vorgehen für EtherChannel/LACP Troubleshooting: Wie Bundles wirklich aufgebaut sind, welche LACP-Indikatoren High-Signal sind, wie Sie Hashing- und Member-Probleme sauber beweisen und wie Sie LAG Splits ohne Blindflug isolieren und beheben.

Begriffe klären: EtherChannel, LAG, LACP und „Bundle“

Im Alltag werden mehrere Begriffe gemischt. Für sauberes Troubleshooting ist eine klare Sprache wichtig, weil sich Konfiguration und Evidence daran orientieren.

• LAG (Link Aggregation Group): Sammelbegriff für ein Bündel aus mehreren physischen Links, die als ein logischer Link betrieben werden.
• EtherChannel: verbreiteter Herstellerbegriff (oft Cisco) für LAG/Port-Channel.
• Port-Channel / Bundle: logisches Interface, das mehrere Members zusammenfasst.
• LACP (Link Aggregation Control Protocol): Protokoll, das Members aushandelt und überwacht.
• Static LAG: Bündel ohne LACP; funktioniert, aber hat weniger Schutz gegen Fehlverkabelung.

Die normative Grundlage für LACP/LAG ist IEEE 802.1AX (historisch 802.3ad). Eine offizielle Einstiegsseite finden Sie über IEEE 802.1AX.

Wie ein LAG technisch funktioniert: Warum „ein Link“ eigentlich viele Links sind

Ein LAG ist kein „magischer dicker Draht“, sondern eine Forwarding-Logik: Frames werden pro Flow auf genau einen Member gelegt, damit Reihenfolge und Paketkonsistenz erhalten bleiben. Deshalb sehen Sie trotz „2×10G“ nicht automatisch 20G für einen einzelnen TCP-Flow. Das ist kein Bug, sondern Design. Die Aggregation wirkt über mehrere Flows hinweg.

• Per-Flow Load Balancing: Ein Flow bleibt auf einem Member (typisch 5-Tuple-Hash).
• Reihenfolge bewahren: Würde man Pakete eines Flows über mehrere Links verteilen, entstehen Reordering und Performanceprobleme.
• Member-Health: Fällt ein Member aus oder wird von LACP „suspended“, muss Hashing und Forwarding sauber reagieren.

Die wichtigsten Fehlerklassen: Warum LAGs in der Praxis kaputtgehen

Die meisten EtherChannel/LACP-Probleme fallen in wiederkehrende Kategorien. Wenn Sie diese Kategorien kennen, können Sie Symptome schneller zuordnen.

• Bundle kommt nicht hoch: LACP verhandelt nicht, Mode-Mismatch, Key/ID passt nicht, Speed/Duplex inkonsistent.
• Bundle ist hoch, aber inkonsistent: einzelne Members haben andere VLANs, MTU, STP-Settings oder Security-Policies.
• Hashing ungleich: ein Member ist überlastet, andere sind leer; einzelne Flows langsam, andere ok.
• LAG Split: jede Seite glaubt, in einem anderen Bundle zu sein; Frames gehen in falsche Richtung, MACs flappen.
• Intermittent Flaps: Members wechseln zwischen aktiv/suspended; erzeugt Latenzspitzen, Retransmits, kurze Aussetzer.

LACP Basics, die Sie im Troubleshooting brauchen

LACP ist kein „Komfortfeature“, sondern ein Schutzmechanismus. Es stellt sicher, dass beide Seiten dieselbe Sicht auf das Bundle haben. Im Incident sind drei LACP-Elemente besonders wichtig: State, Partner-Information und der Aggregation-Key.

LACP Modes und typische Missverständnisse

• Active: sendet LACP PDUs aktiv, verhandelt proaktiv.
• Passive: verhandelt, aber sendet nur, wenn Gegenstelle aktiv ist.
• Static (on): kein LACP; kann bei Fehlverkabelung gefährlich sein (Loops/LAG Split begünstigt).

Praxisregel: Active/Active ist am robustesten. Active/Passive funktioniert, aber erschwert manchmal Diagnose, wenn PDUs nicht sichtbar sind. Static sollte nur bewusst und mit klaren Guardrails eingesetzt werden.

Welche LACP-Signale High-Signal sind

• Partner MAC/ID: stimmt die Gegenstelle pro Member wirklich überein?
• Synchronization/Collecting/Distributing: ist ein Member wirklich im Datenpfad oder nur „up“?
• Suspended/Individual: Member wird ausgeschlossen, weil Parameter nicht passen.
• Timeout/Rate: Fast vs. Slow Timers beeinflussen Erkennungszeit (und manchmal Flap-Verhalten).

Bundle kommt nicht hoch: Der klassische „LACP up/up, aber kein Port-Channel“ Fall

Wenn ein Port-Channel nicht zustande kommt, ist die Ursache fast immer eine Inkonsistenz, die LACP oder die Plattform als „nicht aggregierbar“ bewertet. Hier hilft ein striktes Checkschema, statt Konfig „hin und her“ zu schrauben.

Checkliste für „kommt nicht hoch“

• Speed/Duplex: alle Members identisch, keine Autoneg-Sonderfälle (besonders bei Kupfer/Medienkonvertern).
• MTU: identisch auf allen Members und auf dem logischen Port-Channel (inkl. QinQ/Overlay-Overhead, falls relevant).
• Trunk/Access Mode: beide Seiten müssen den gleichen L2-Modus haben (Trunk↔Trunk, Access↔Access).
• Allowed VLANs / Native VLAN: müssen konsistent sein, sonst werden Members oft suspended oder erzeugen später Fehler.
• LACP Mode: active/passive Kombination prüfen; static vs. LACP darf nicht gemischt werden.
• Key/System ID: Partner-Infos müssen konsistent sein (falscher Nachbar, falsches Patchen, falsches Crossconnect).

Bundle ist „up“, aber Traffic ist kaputt: Der gefährlichste Zustand

Der kritischste LAG-Zustand ist ein logisches Interface, das „up“ ist, aber inkonsistent arbeitet. Dann wirkt das Netz instabil, obwohl Monitoring „grün“ ist. Die Ursache liegt häufig in Member-Drift: Ein Member hat andere VLANs, andere STP- oder Guard-Policies, oder wird asymmetrisch genutzt.

Typische Symptome eines inkonsistenten Bundles

• Nur manche VLANs betroffen: VLAN 10 ok, VLAN 20 tot → Allowed VLAN fehlt auf einem Member oder auf einer Seite.
• Nur manche Flows betroffen: Hash trifft fehlerhaften Member → sporadische Timeouts, Retransmits, „random“ Paketverlust.
• MAC-Flapping: MAC-Adresse wird mal über Member A, mal über Member B gelernt, weil Forwarding falsch verteilt oder Loop entsteht.
• STP/Guard Events: Root Guard/Loop Guard/BPDU Guard triggert unerwartet auf einem Member (Transit/Edge falsch).

Evidence Pack für „Bundle up, aber kaputt“

• Port-Channel Status: welche Members sind wirklich „collecting/distributing“?
• Member-Counter: CRC/Errors, Discards, Output Drops pro Member (nicht nur am Port-Channel).
• VLAN-Consistency: Allowed VLANs, Native VLAN, Tagging-Settings pro Member und auf dem Port-Channel.
• MAC-Table Moves: MAC-Flapping-Logs und CAM-Moves im betroffenen VLAN.
• STP Port Roles: sind alle Members gleich behandelt? (Transit vs. Edge)

Hashing verstehen: Warum „2×10G“ nicht automatisch „20G“ pro Transfer bedeutet

Hashing ist der häufigste Grund für Performance-Tickets im LAG-Kontext. Ein einzelner TCP-Flow wird in der Regel auf genau einen Member gelegt. Wenn der Hash unglücklich ist (z. B. viele Flows teilen denselben Hash-Key), kann ein Member überlastet sein, während andere idle sind.

Was Hashing typischerweise nutzt

• Layer-2 Hash: Source/Destination MAC
• Layer-3 Hash: Source/Destination IP
• Layer-4 Hash: Source/Destination Ports + Protokoll (5-Tuple)

High-Signal Indizien für Hashing-Ungleichgewicht

• Ein Member heiß, andere kalt: Utilization pro Member stark unterschiedlich.
• Einzelne Anwendungen betroffen: z. B. ein großer Filetransfer langsam, viele kleine Sessions ok.
• Flow-Stickiness: betroffene Clients sind reproduzierbar langsam, weil ihr Hash konstant auf denselben Member fällt.

Was Sie tun können, ohne „mehr Bandbreite“ zu kaufen

• Hash-Policy anpassen: Wenn möglich, auf L3/L4-Hash erweitern, damit mehr Entropie entsteht.
• Flow-Shaping auf Applikationsebene: mehrere parallele Streams (wo sinnvoll) verteilen Last besser.
• Member-Health prüfen: Ungleichgewicht kann auch entstehen, wenn ein Member Errors/Drops hat und Traffic „klebt“.

LAG Split: Wenn beide Seiten unterschiedliche Realität sehen

LAG Split ist ein Sammelbegriff für Zustände, in denen ein LAG nicht symmetrisch ist: Auf Seite A sind andere Members aktiv als auf Seite B, oder die Bündelung ist logisch nicht dieselbe. Das kann durch Fehlverkabelung, LACP-Mismatch, Static-LAG-Fehler oder Multi-Chassis-Designs (MLAG/vPC) passieren. Die Symptome reichen von MAC-Flapping bis zu totalem Blackholing einzelner VLANs.

Typische Ursachen für LAG Split

• Fehlverkabelung: ein Member führt zu einem anderen Switch als geplant (besonders kritisch ohne MLAG/vPC).
• Static auf einer Seite, LACP auf der anderen: beide glauben, es sei „ok“, aber Verhandlung fehlt.
• LACP Key/Mode mismatch: Mitglieder werden unterschiedlich aggregiert oder bleiben „individual“.
• MLAG/vPC Peer-Link Probleme: Peer-Link down, Keepalive-Fehler, Split-Brain-Schutzmechanismen greifen.

High-Signal Nachweise für LAG Split

• Partner-IDs pro Member: zeigen unterschiedliche Partner-Systeme (falscher Nachbar).
• MAC-Flapping-Logs: MACs wechseln zwischen den LAG-Members oder zwischen Switches.
• Asymmetrische Forwarding-States: Member A ist auf Seite A distributing, auf Seite B suspended.

Intermittent Issues: Wenn Members flappen und niemand weiß warum

Flappende Members sind besonders unangenehm, weil sie kurze, wiederkehrende Störungen erzeugen: Mikro-Aussetzer, TCP Retransmits, kurze Latenzspitzen. Die Ursache ist oft physikalisch (Optics/Kabel), kann aber auch durch LACP Timer, CPU-Pressure, Fehler in Zwischenkomponenten oder durch inkonsistente Einstellungen ausgelöst werden.

Typische Indikatoren

• LACP Timeout Events: Partner PDUs fehlen kurzzeitig.
• Interface Errors: CRC/Symbol Errors (Physik) oder Discards/Drops (Queueing/Policy) auf einem Member.
• Optics DOM Drift: Rx Power/Temperatur/Bias schwanken, Link bleibt „up“, aber Qualität ist marginal.
• Member nur unter Last schlecht: Fehler steigen bei höherer Auslastung (marginaler Link/Transceiver).

PCAP und Protokollsicht: Wann Mitschnitte helfen

Für LACP- und L2-Forensik sind Captures oft hilfreich, wenn Logs unklar sind oder Sie beweisen müssen, was wirklich am Draht passiert. Ein Capture kann LACP PDUs, VLAN-Tags, MAC-Flapping-Muster und Timing sichtbar machen. Arbeiten Sie kurz, gefiltert und an der richtigen Stelle (vorzugsweise nah am betroffenen Member).

• LACP PDUs: zeigen Partner-System-ID, Key, State (collecting/distributing) und Timing.
• 802.1Q Tags: belegen VLAN-Fehler in Allowed/Native/Tagging.
• Folgeeffekte: ARP-Anomalien, Retransmissions bei L3/L4-Tests (sekundäre Evidence).

Für praktische Analyse-Workflows sind die Wireshark-Dokumentation und die tcpdump-Manpage solide Referenzen.

Systematisches Troubleshooting: Ein Ablauf, der im On-Call funktioniert

Der größte Fehler bei EtherChannel/LACP Troubleshooting ist, direkt „am Port-Channel zu drehen“, ohne Member und Gegenstelle einzubeziehen. Nutzen Sie stattdessen eine feste Reihenfolge, die schnell zur Fehlerdomäne führt.

Schritt 1: Scope und Symptomtyp klassifizieren

• Kommt der Port-Channel hoch oder nicht?
• Ist nur Performance betroffen (Hashing) oder echte Connectivity (VLAN/Bundle inkonsistent)?
• Ist es sporadisch (Member flaps) oder konstant (Misconfig)?

Schritt 2: LACP Zustand und Partner-Konsistenz prüfen

• Sind alle Members synchronisiert und distributing/collecting?
• Sehen alle Members denselben Partner (System ID)?
• Gibt es suspended/individual Members? Warum?

Schritt 3: Member-Consistency prüfen (nicht nur logisch)

• VLANs (Allowed/Native), Trunk/Access Mode, STP-Settings pro Member
• MTU und ggf. QinQ/Overlay-Overhead
• Speed/Duplex/Autoneg und physische Qualität (Errors, Optics DOM)

Schritt 4: Hashing und Lastverteilung bewerten

• Utilization pro Member vergleichen
• Betroffene Flows identifizieren (welche Clients/Ports sind langsam?)
• Hash-Policy prüfen und ggf. verbessern

Schritt 5: Low-Risk Mitigation und Verifikation

• Fehlerhaften Member kontrolliert drainen/disable (wenn Evidence stark ist)
• Allowed VLANs/Native konsistent machen (kleine, kontrollierte Änderung)
• Verifikation: MAC-Flaps stoppen, Drops/Errors sinken, Service stabil

Fixes ohne Blindflug: Was nachhaltig hilft

Ein guter Fix stellt Konsistenz her und reduziert Drift-Risiko. Die häufigsten nachhaltigen Maßnahmen sind organisatorisch und technisch zugleich.

• Konfig-Templates: Port-Channel und Members immer aus einem Template provisionieren, nicht „per Hand“.
• Consistency Checks automatisieren: Allowed VLANs, MTU, STP, LACP Mode, Speed/Duplex pro Member vergleichen.
• Static LAG vermeiden: LACP als Schutz gegen Fehlverkabelung nutzen (wo möglich).
• Member-Telemetrie standardisieren: nicht nur Port-Channel-Metriken, sondern pro Member Errors/Drops/Utilization.
• Change-Markierung: LAG-Änderungen als Events im Monitoring anzeigen, damit Incidents schnell korrelierbar sind.

Runbook-Baustein: EtherChannel/LACP in 15 Minuten eingrenzen

• Minute 0–3: Symptom klassifizieren (nicht hoch vs. hoch aber kaputt vs. Performance/Hashing vs. sporadisch).
• Minute 3–6: LACP State prüfen: collecting/distributing, suspended/individual, Partner IDs pro Member.
• Minute 6–9: Member-Consistency: VLANs/Native, MTU, STP/Guard, Speed/Duplex, Errors/Drops pro Member.
• Minute 9–12: Hashing prüfen: Utilization pro Member, betroffene Flows identifizieren, Hash-Policy bewerten.
• Minute 12–15: Low-Risk Mitigation: fehlerhaften Member drainen oder Consistency-Fix; danach Verifikation über MAC-Flaps, Drops/Errors und Servicechecks.

Weiterführende Quellen für Standards und Analysepraxis

• IEEE 802.1AX als Referenzrahmen für Link Aggregation und LACP
• IEEE 802.1Q für Bridging/VLAN-Kontext, der bei Trunk-/Allowed-VLAN-Problemen im LAG relevant ist
• Wireshark Dokumentation für LACP- und VLAN-Tag-Analyse in Captures
• tcpdump Manpage für effiziente Captures und BPF-Filter (auch auf Trouble-Members)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.