EtherChannel erhöht Bandbreite und Redundanz, aber die Lastverteilung passiert nicht „magisch“: Switches verteilen Traffic über die Member-Links per Hashing-Algorithmus. Wenn das Hashing nicht zur Traffic-Struktur passt, kann ein einzelner Link überlaufen, während andere Member kaum genutzt werden. Besonders häufig ist das bei wenigen großen Flows, bei einseitigen Traffic-Mustern oder bei ungünstigen Hash-Schlüsseln (nur MAC statt IP/Ports). Dieser Leitfaden erklärt, wie EtherChannel Load-Balancing auf Cisco funktioniert, welche Hash-Optionen es gibt und wie du sie praxisnah richtig einstellst und prüfst.
Grundprinzip: Warum ein einzelner Flow nicht „schneller“ wird
EtherChannel verteilt typischerweise pro Flow, nicht pro Paket. Das schützt die Reihenfolge (Packet Ordering), bedeutet aber: Ein einzelner TCP-Flow bleibt meist auf einem Member-Link. Erst viele parallele Flows nutzen mehrere Links effektiv.
- Per-Flow Hashing verhindert Out-of-Order Pakete
- Ein großer Flow nutzt meist nur einen Member
- Viele Flows (viele Clients/Server) verteilen sich besser
Merksatz für die Praxis
EtherChannel skaliert mit der Anzahl unabhängiger Flows. Wenn du nur „einen dicken Datenstrom“ hast, brauchst du ggf. andere Maßnahmen (z. B. ECMP, Applikations-Parallelisierung, mehrere Sessions).
Welche Hash-Schlüssel gibt es? MAC, IP, L4-Ports
Der Hash wird aus ausgewählten Header-Feldern gebildet. Je mehr Varianz in diesen Feldern existiert, desto besser kann der Traffic verteilt werden.
- MAC-basiert: nutzt Source/Destination MAC – gut in reinen L2-Szenarien, aber oft wenig Varianz
- IP-basiert: nutzt Source/Destination IP – besser bei geroutetem Traffic
- L4-basiert: nutzt zusätzlich TCP/UDP-Ports – beste Varianz bei vielen Sessions
Typischer Effekt in Enterprise-Netzen
In Campus-/DC-Uplinks ist IP- oder L4-basiertes Hashing meist sinnvoller als reines MAC-Hashing, weil viele Clients/Server über Routing miteinander sprechen.
Aktuelles Load-Balancing auf Cisco prüfen
Bevor du etwas umstellst, prüfe den aktuellen Hash-Algorithmus. Die verfügbaren Optionen hängen von Plattform und IOS/IOS XE ab.
show etherchannel load-balance
Port-Channel und Member-Zustand verifizieren
show etherchannel summary
show interfaces port-channel 1
Hashing einstellen: globalseitig (wichtiger Punkt)
Auf vielen Cisco Switches ist der Load-Balancing-Algorithmus global für das Gerät, nicht pro Port-Channel. Das bedeutet: Eine Änderung kann mehrere EtherChannels beeinflussen. Plane Changes entsprechend und dokumentiere sie.
Typische Hash-Optionen anzeigen
Nutze die Kontext-Hilfe, um die auf deinem Gerät verfügbaren Methoden zu sehen.
configure terminal
port-channel load-balance ?
end
Beispiel 1: IP-basiertes Hashing setzen
Geeignet, wenn die meisten EtherChannels L3-Traffic transportieren und viele unterschiedliche IPs vorkommen.
configure terminal
port-channel load-balance src-dst-ip
end
Beispiel 2: L4-basiertes Hashing setzen
Geeignet, wenn viele TCP/UDP-Sessions zwischen gleichen IP-Paaren existieren (z. B. Serverfarmen, Proxy/Loadbalancer-Szenarien). Dadurch steigt die Varianz stark.
configure terminal
port-channel load-balance src-dst-port
end
Beispiel 3: MAC-basiertes Hashing (L2-lastig)
In reinen L2-Domänen oder bei bestimmten Designs kann MAC-basiert sinnvoll sein, ist aber häufig anfälliger für „Ungleichgewicht“, wenn wenige MAC-Paare dominieren.
configure terminal
port-channel load-balance src-dst-mac
end
Welche Einstellung ist „richtig“? Praxis-Entscheidung nach Traffic-Typ
Die richtige Wahl hängt davon ab, welche Header-Felder im Traffic variieren. Wähle das Hashing so, dass es möglichst viele unterschiedliche Werte sieht.
- Access ↔ Distribution (viele Clients): src-dst-ip oder src-dst-port
- Core/Distribution mit starkem Routing: src-dst-ip ist oft guter Standard
- Serverfarm/Proxy/Loadbalancer: src-dst-port kann deutliche Vorteile bringen
- Reine L2-Trunks ohne Routing: src-dst-mac kann ausreichend sein, aber prüfen
Warnsignal: „Eine Quelle spricht mit einem Ziel“
Wenn ein einzelner Host (oder eine einzelne IP) fast alles sendet, wird selbst L4-Hashing nicht immer perfekt sein – dann hilft nur mehr Flow-Parallelität oder ein anderes Design.
Nachweis der Verteilung: Wie du siehst, ob alle Links genutzt werden
Du willst prüfen, ob Member-Links Traffic tragen und ob ein Member überproportional ausgelastet ist. Dafür kombinierst du Port-Channel Status mit Interface Counters.
Traffic pro Member ansehen
show interfaces port-channel 1
show interfaces gigabitEthernet 1/0/47
show interfaces gigabitEthernet 1/0/48
Counters und Drops prüfen
show interfaces counters errors
show interfaces gigabitEthernet 1/0/47 | include rate|drops|error
show interfaces gigabitEthernet 1/0/48 | include rate|drops|error
Typische Ursachen für schlechtes Load-Balancing
Wenn die Verteilung „schief“ ist, ist das oft kein Defekt, sondern ein Musterproblem. Die wichtigsten Ursachen sind wenige Flows, NAT/Proxy-Konzentration oder ein Hash, der zu wenig Varianz sieht.
- Nur wenige große Flows (z. B. ein Backup-Stream)
- NAT/Proxy bündelt viele Clients hinter einer IP
- MAC-Hashing in gerouteten Szenarien mit wenig MAC-Varianz
- Asymmetrischer Traffic (eine Richtung dominiert)
- Member-Link mit Errors/Speed-Mismatch wirkt „langsamer“
Physische Qualität als Voraussetzung
Wenn ein Member Errors hat (CRC/Drops), sieht es schnell nach „schlechtem Hashing“ aus, ist aber ein Layer-1-Thema.
show interfaces counters errors
show logging | include CRC|ERROR|LINK|LINEPROTO
Change-Sicherheit: Hashing-Änderung sauber durchführen
Da die Einstellung oft global wirkt, führe Changes kontrolliert durch: Ist-Zustand dokumentieren, Änderung setzen, Verteilung prüfen, dann speichern. Plane ein Wartungsfenster, wenn EtherChannels kritisch sind.
Pre-/Post-Check (Spickzettel)
show etherchannel load-balance
show etherchannel summary
show interfaces port-channel 1
show interfaces gigabitEthernet 1/0/47
show interfaces gigabitEthernet 1/0/48
Konfiguration speichern
copy running-config startup-config
Best Practices: Stabil und vorhersehbar load-balancen
Gutes EtherChannel Load-Balancing ist eine Kombination aus passendem Hash, sauberer Traffic-Verteilung und stabilen Links. Mit diesen Standards reduzierst du Engpässe und Überraschungen.
- Für gerouteten Traffic meist src-dst-ip oder src-dst-port bevorzugen
- Hashing-Änderungen als globalen Change behandeln und dokumentieren
- Viele Flows fördern (z. B. parallele Sessions bei Backups, wenn möglich)
- Member-Links regelmäßig auf Errors/Drops prüfen
- Port-Channels konsistent konfigurieren und verifizieren
show etherchannel load-balance
show interfaces counters errors
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.
