Wenn ein EtherChannel nicht bündelt oder „instabil“ wirkt, liegt die Ursache fast immer in LACP-States oder in Konfig-Inkonsistenzen zwischen den Member-Ports. Typische Symptome sind: Port-Channel bleibt down, einzelne Member stehen „suspended“, Trunks transportieren VLANs nur teilweise oder STP behandelt plötzlich Einzelports statt den Port-Channel. Wer die LACP-Zustände richtig liest und die klassischen Fallen systematisch prüft, findet den Fehler schnell – ohne riskantes „Try & Error“ an produktiven Uplinks.
Start: In 2 Minuten den Ist-Zustand erfassen
Beginne mit dem Überblick: Ist der Port-Channel up? Welche Member sind wirklich gebündelt? Siehst du LACP-Nachbarn? Danach gehst du in Member-Details und Trunk-Parameter.
show etherchannel summary
show etherchannel port-channel
show lacp neighbor
show interfaces port-channel 1
show interfaces trunk
LACP States verstehen: Was „P“, „I“, „S“ & Co. bedeuten
Der Output von show etherchannel summary nutzt Kurzflags. Diese Flags sind der schnellste Hinweis, warum ein Link nicht bündelt. Die genaue Darstellung variiert je nach Plattform, die Logik ist aber gleich: „gebündelt“ vs. „nicht im Bundle“.
Typische Flags in show etherchannel summary (praxisnah)
- P: Port ist im Bundle (bundled)
- I: Stand-alone / individual (nicht gebündelt)
- S: Layer-2 (Switchport) Channel
- U: Port-Channel ist up
- D: Port-Channel ist down
Interpretation in einem Satz
Wenn du keine „P“-Member siehst, gibt es keinen funktionierenden EtherChannel – dann sind Protokoll, Konfig-Konsistenz oder Physik der Fehler.
show lacp neighbor: Prüfen, ob LACP überhaupt verhandelt
Ohne LACP-Nachbarn gibt es nichts zu bündeln. Das kann an falschen Modi (passive/passive), falschem Protokoll (PAgP vs. LACP) oder physischer Trennung liegen.
show lacp neighbor
show lacp internal
Häufigste LACP-Aushandlungsfehler
- LACP passive ↔ passive: kein Aufbau
- LACP ↔ PAgP gemischt: kein Aufbau
- Eine Seite statisch „on“, andere LACP: instabil/kein Bundle
Schneller Fix: LACP beidseitig aktiv setzen
configure terminal
interface range gigabitEthernet 1/0/47 - 48
channel-group 1 mode active
end
Typische Konfig-Falle 1: Member-Ports sind nicht identisch
EtherChannel ist extrem strikt: Alle Member müssen „gleichartig“ sein. Schon kleine Abweichungen (Access vs. Trunk, Native VLAN, Allowed VLANs) führen dazu, dass Ports nicht bündeln oder suspended werden.
Member-Konfiguration vergleichen
show running-config interface gigabitEthernet 1/0/47
show running-config interface gigabitEthernet 1/0/48
show interfaces gigabitEthernet 1/0/47 switchport
show interfaces gigabitEthernet 1/0/48 switchport
Typische Inkonsistenzen
- Ein Member ist Access, der andere Trunk
- Allowed VLANs unterscheiden sich (auch Reihenfolge/Format ist egal, Inhalt zählt)
- Native VLAN unterschiedlich
- STP-/Security-Features nur auf einem Member (z. B. PortFast trunk)
- Speed/Duplex/Medientyp nicht identisch
Typische Konfig-Falle 2: Port-Channel Interface ist nicht sauber gesetzt
In der Praxis gehört die finale Switchport-Konfiguration auf das port-channel-Interface. Wenn du nur Member konfigurierst, kann es zu „geerbten“ oder inkonsistenten Zuständen kommen.
Port-Channel Konfiguration prüfen
show running-config interface port-channel 1
show interfaces port-channel 1 switchport
Sauberes Trunk-Template (Member + Port-Channel)
configure terminal
vlan 999
name NATIVE-UNUSED
exit
interface range gigabitEthernet 1/0/47 - 48
description UPLINK-LACP
switchport mode trunk
switchport trunk allowed vlan 10,20,30,99
switchport trunk native vlan 999
channel-group 1 mode active
exit
interface port-channel 1
description UPLINK-LACP
switchport mode trunk
switchport trunk allowed vlan 10,20,30,99
switchport trunk native vlan 999
end
Typische Konfig-Falle 3: Trunk transportiert VLANs nicht (Allowed VLANs / Native)
Ein Port-Channel kann technisch up sein, aber VLANs fehlen trotzdem, wenn Allowed VLANs falsch sind oder Native VLAN mismatched ist. Das wirkt dann wie „VLAN-Problem“, ist aber EtherChannel/Trunk-Policy.
Trunk-Output prüfen
show interfaces trunk
show interfaces port-channel 1
show logging | include NATIVE|VLAN|TRUNK
Typische Konfig-Falle 4: STP sieht Einzelports statt Port-Channel
Wenn STP einzelne Member-Ports als eigenständige Links behandelt, ist das ein starkes Zeichen, dass der EtherChannel nicht korrekt gebündelt ist. In einem sauberen Bundle ist STP auf dem Port-Channel aktiv.
STP am Port-Channel prüfen
show spanning-tree interface port-channel 1 detail
show spanning-tree interface gigabitEthernet 1/0/47 detail
show spanning-tree interface gigabitEthernet 1/0/48 detail
Typische Konfig-Falle 5: Physische Probleme auf einem Member (CRC/Flaps)
Ein Member mit CRC/Errors oder Link-Flaps führt zu intermittierendem Bundling. Der Port-Channel bleibt oft up, aber Kapazität schwankt und Troubleshooting wird „schwammig“.
Errors und Flaps prüfen
show interfaces counters errors
show interfaces gigabitEthernet 1/0/47
show interfaces gigabitEthernet 1/0/48
show logging | include LINK|LINEPROTO|CRC|ERROR
Typische Konfig-Falle 6: Falsche Channel-Group oder Member fehlen
Wenn ein Port nicht in der richtigen Channel-Group ist oder ein Member vergessen wurde, wirkt der Bundle unvollständig. Prüfe daher Channel-Group Zuordnung konsequent.
Channel-Group Zuordnung prüfen
show etherchannel summary
show running-config | include channel-group
Quick-Fix: Member sauber neu zuordnen
configure terminal
interface range gigabitEthernet 1/0/47 - 48
no channel-group
channel-group 1 mode active
end
Playbook: EtherChannel-Probleme in 10 Minuten lösen
Dieses Vorgehen ist robust und verhindert Aktionismus. Du gehst von Protokoll → Bundle → Konfig-Konsistenz → Trunk/STP → Physik.
- 1)
show etherchannel summary: Sind Member „P“? Ist Po „U“? - 2)
show lacp neighbor: Siehst du die Gegenstelle? - 3) Member-Konfig vergleichen (Access/Trunk, VLANs, Native)
- 4) Port-Channel Interface prüfen (Switchport-Settings final dort)
- 5) Trunk prüfen (allowed+active, Native mismatch)
- 6) STP prüfen (STP muss Po sehen, nicht Einzelports)
- 7) Physik prüfen (CRC, Flaps, SFPs)
show etherchannel summary
show lacp neighbor
show interfaces port-channel 1 switchport
show interfaces trunk
show spanning-tree interface port-channel 1 detail
show interfaces counters errors
Best Practices: LACP stabil und auditierbar betreiben
EtherChannel ist sehr zuverlässig, wenn du ihn standardisierst: LACP als Default, identische Member-Configs, Trunks whitelisted und Native VLAN ungenutzt. Damit verschwinden die meisten „bündelt nicht“-Tickets.
- LACP active/active oder active/passive (nie passive/passive)
- Member-Ports immer per
interface rangeidentisch konfigurieren - Port-Channel Interface separat konfigurieren (Trunk/Allowed/Native)
- Allowed VLANs whitelisten, Native VLAN ungenutzt setzen
- Physik überwachen: CRC/Flaps pro Member
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
