February 15, 2026

LACP & MLAG: Redundanz ohne Loops designen

LACP & MLAG: Redundanz ohne Loops designen ist im Enterprise und im Data Center ein zentrales Thema, weil Sie gleichzeitig drei Ziele erreichen müssen: hohe Verfügbarkeit, gute Linkauslastung und stabile Layer-2-Topologien. Klassische Redundanz mit zwei parallelen Uplinks führt in Layer 2 schnell zu Schleifen – und damit zu Broadcast-Stürmen, MAC-Flapping und schwer eingrenzbaren Incidents. Spanning Tree (STP/RSTP/MSTP) verhindert Loops zwar, blockiert aber oft einen Teil der Kapazität und erzeugt im Fehlerfall Topologieänderungen, die sich großflächig auswirken können. LACP (Link Aggregation Control Protocol) löst dieses Dilemma teilweise, indem mehrere physische Links zu einem logischen Bündel zusammengefasst werden, das für Switches und Hosts wie eine einzige Verbindung wirkt. MLAG (Multi-Chassis Link Aggregation) geht einen Schritt weiter: Es erlaubt, ein LACP-Bündel über zwei physische Switches hinweg zu terminieren, sodass Endgeräte oder Access-Switches aktiv/aktiv redundant angebunden werden können, ohne dass STP auf den Uplinks zwingend blocken muss. Das klingt nach der perfekten Lösung – ist es aber nur, wenn Design, Failure-Modes, Schutzmechanismen und Betrieb diszipliniert umgesetzt sind. Dieser Artikel erklärt die Grundlagen von LACP und MLAG, zeigt typische Architekturvarianten, beschreibt häufige Fehlerbilder und liefert konkrete Design- und Mitigation-Techniken, damit Redundanz ohne Loops im Alltag tatsächlich stabil funktioniert.

Table of Contents

Grundlagen: Warum Redundanz in Layer 2 ohne Mechanismen gefährlich ist

Layer 2 kennt kein Hop-Limit. Wenn ein Frame in eine Schleife gerät, kann er unbegrenzt zirkulieren und wird durch Flooding vervielfacht. Das Problem eskaliert häufig schneller, als Monitoring und On-Call reagieren können. Ohne Loop-Prevention entsteht aus „zwei Uplinks zur Sicherheit“ ein potenzieller Ausfallfaktor. Klassische Gegenmaßnahmen sind STP-Varianten, die Links blockieren, um eine loop-freie Baumstruktur zu erzwingen. Für viele Campus- und Access-Designs ist das weiterhin sinnvoll, im Data Center oder in hochdichten Server-Umgebungen ist blockierte Kapazität jedoch teuer.

Ohne Mechanismen: Redundanz erzeugt Loops → Storms, MAC-Flaps, Degradation bis zum Ausfall.
Mit STP: Loops werden verhindert, aber Kapazität wird blockiert und Konvergenz kann operational spürbar sein.
Mit LACP/MLAG: Redundanz kann aktiv genutzt werden, wenn die Bündelung korrekt designt ist.

LACP erklärt: Link Aggregation als logisches Bündel

LACP fasst mehrere physische Links zu einem logischen Link Aggregation Group (LAG) zusammen. Für die Forwarding-Logik gilt dann: Das Bündel ist eine Verbindung, die intern aus mehreren Member-Links besteht. Der Traffic wird über Hashing auf die Member verteilt, wodurch Bandbreite skaliert und Redundanz entsteht. Fällt ein Member aus, bleibt das Bündel bestehen, nur die Kapazität sinkt.

Aktiv/aktiv Nutzung: alle Member-Links können gleichzeitig Traffic tragen.
Redundanz: Link-Ausfälle führen zu Degradation, nicht zwingend zu Unterbrechung.
Stabilität: LACP verhandelt Parameter und stellt sicher, dass beide Seiten kompatibel bündeln.

Als technische Referenz für Link Aggregation ist der Anchor-Text IEEE 802.1AX (Link Aggregation) relevant. Viele Implementierungen sind historisch aus IEEE 802.3ad hervorgegangen und wurden in 802.1AX konsolidiert.

Wie LACP Traffic verteilt: Hashing und seine Konsequenzen

LACP erhöht die Gesamtkapazität eines Bündels, aber nicht jeder einzelne Flow bekommt automatisch „mehr Bandbreite“. Die Verteilung erfolgt typischerweise über einen Hash aus Header-Feldern (z. B. Quell-/Ziel-MAC, VLAN, IPs, TCP/UDP-Ports). Das bedeutet: Viele kleine Flows verteilen sich gut, wenige große Flows können auf einzelne Member „kleben“ und Hotspots erzeugen.

Vereinfachtes Modell für die Bündelkapazität

$Kapazität = AnzahlMember \times LinkSpeed$

Dieses Modell beschreibt die maximale aggregierte Kapazität. Für einen einzelnen Flow gilt dagegen näherungsweise: Er wird einem Member zugeordnet und ist dann durch dessen LinkSpeed begrenzt. Deshalb ist es im Design wichtig, Hash-Algorithmen und Workload-Muster zu berücksichtigen.

Typische LACP-Designs: Server, Access, Uplinks

LACP wird in Enterprise-Umgebungen häufig in drei Kontexten eingesetzt: Server-Uplinks (z. B. Hypervisor), Access-Uplinks (z. B. ToR/End-of-Row) und Aggregationslinks im Netz. Die Designprinzipien sind ähnlich, aber die Failure-Modes unterscheiden sich.

Server-Bonding (NIC Teaming): Host nutzt LACP, Switch terminiert LAG; wichtig sind konsistente MTU, VLAN-Tagging und klare Portrollen.
Access-Uplinks: Access-Switch bündelt Uplinks; ohne MLAG führt Dual-Homing zu STP-Blocking oder aktiver/passiver Nutzung.
Inter-Switch-LAG: Bündel zwischen Switches; besonders wichtig sind Konsistenz von Allowed VLANs und saubere STP-/Loop-Guardrails.

Was MLAG ist: LACP über zwei Switches hinweg

MLAG (auch als vPC, MC-LAG, mLAG oder ähnlich bezeichnet) erweitert LACP, indem zwei physische Switches gemeinsam wie eine logische Gegenstelle erscheinen. Ein Endgerät oder Access-Switch kann damit ein einziges LACP-Bündel zu zwei Switches aufbauen. Der praktische Effekt: Beide Uplinks sind aktiv, ohne dass STP zwingend einen Link blocken muss. MLAG ist in vielen Data-Center- und Enterprise-Designs ein Standardbaustein, weil es die Verfügbarkeit erhöht und die Bandbreite besser nutzt.

Dual-Homing ohne Blocking: beide Uplinks aktiv, Redundanz ohne STP-Block auf den Uplinks.
Schneller Failover: bei Ausfall eines Switches oder Links bleibt der andere Pfad aktiv.
Komplexität: MLAG ist häufig vendor-spezifisch in Details; Failure-Modes müssen verstanden und getestet sein.

Als Einstieg in herstellerspezifische Ausprägungen eignen sich die Dokumentationen Cisco vPC (Konzept und Betrieb), Arista MLAG (EOS User Manual) und Juniper MC-LAG (Überblick).

MLAG-Architekturbausteine: Peer-Link, Keepalive und State-Synchronisation

Auch wenn Begriffe je nach Hersteller variieren, bestehen MLAG-Systeme typischerweise aus drei Kernelementen:

Peer-Link: hochverfügbarer Interconnect zwischen den beiden MLAG-Peers. Darüber werden Zustände synchronisiert und häufig auch Datenverkehr in Sonderfällen übertragen.
Keepalive/Heartbeat: separater Pfad oder Mechanismus, um Peer-Liveness zu erkennen, falls der Peer-Link gestört ist.
Control-/State-Sync: Abstimmung über LACP-Zustand, MAC-Learning, VLAN-/Portzustände, je nach Implementierung.

Im Design ist entscheidend, den Peer-Link nicht „irgendwie“ zu bauen. Er ist ein kritischer Bestandteil der Failure-Story und muss in Kapazität, Redundanz und Monitoring so behandelt werden wie eine zentrale Komponente.

Failure-Modes, die Sie kennen müssen: Wo Redundanz kippt

MLAG verbessert Redundanz, aber er schafft neue Fehlerbilder, die ohne klare Guardrails zu großen Incidents führen können. Die wichtigsten Failure-Klassen sind:

Peer-Link-Down bei intaktem Keepalive: kann je nach Implementierung zu Schutzaktionen führen (z. B. Ports herunterfahren), um Split-Brain zu verhindern.
Split-Brain: beide Peers glauben, sie seien „aktiv“, und nehmen unabhängig Entscheidungen; Risiko für Loops, MAC-Flaps oder Blackholing.
Asymmetrisches VLAN-/Trunking-Setup: Allowed VLANs oder Native VLANs sind nicht identisch → schwer zu debuggen, oft nur partielle Ausfälle.
MAC-Flapping über Peers: durch falsche Verkabelung, falsche LACP-Modi oder unklare Rollen kann eine MAC abwechselnd auf beiden Peers gelernt werden.
Peer-Link als Flaschenhals: in bestimmten Traffic-Szenarien kann Datenverkehr unerwartet über den Peer-Link laufen und diesen überlasten.

Redundanz ohne Loops: Designprinzipien, die in großen Netzen tragen

Ein robustes LACP-&-MLAG-Design beginnt nicht bei Kommandos, sondern bei Prinzipien. Diese reduzieren Komplexität und machen Failure-Modes beherrschbar.

Klare Portrollen: Server-Port, Access-Uplink, Peer-Link, Keepalive, Upstream-Uplink – jeweils mit eigenen Templates.
Symmetrie als Pflicht: Trunking, VLAN-Listen, MTU, QoS und LACP-Parameter müssen auf beiden Peers konsistent sein.
Minimale L2-Fault-Domains: MLAG ist kein Freibrief für VLAN-Stretching über große Bereiche; L3-Boundaries bleiben wichtig.
Peer-Link redundant: als LAG aufgebaut, mit ausreichender Kapazität und klaren Monitoring-Schwellen.
Guardrails aktivieren: Storm Control, BPDU Guard/Filter (wo passend), MAC-Limits, Loop-Protection am Edge.

LACP-Parameter und Betriebsentscheidungen: Active/Passive, Timer, Min-Links

Viele LACP-Probleme entstehen durch unklare oder inkonsistente Parameterwahl. Besonders relevant sind:

LACP Mode (active/passive): „active“ sendet LACP-PDUs aktiv, „passive“ wartet. Für zuverlässige Aushandlung ist active/active in vielen Umgebungen die betriebssicherste Wahl.
Timer (fast/slow): beeinflusst, wie schnell Link-Status erkannt und umgesetzt wird; schnelle Timer verbessern Reaktionszeit, erhöhen aber die Empfindlichkeit gegenüber kurzen Störungen.
Minimum Links: definiert, ab welcher Anzahl aktiver Member das Bündel als „up“ gilt; schützt vor unerwartet kleiner Restkapazität.

Min-Links als einfache Verfügbarkeitsbedingung

$Bündel_Up = AktiveMember \geq MinLinks$

Diese Regel hilft besonders bei kritischen Uplinks: Lieber ein klares „down“ mit Failover auf Alternativen, als ein „halb kaputtes up“, das Anwendungen mit unzureichender Kapazität degradiert.

Interaktion mit STP: Wann STP bleibt und wann es nur noch Safety-Net ist

LACP und MLAG ersetzen STP nicht automatisch. STP bleibt in vielen Umgebungen sinnvoll – vor allem als Sicherheitsnetz gegen Fehlpatching und unerwartete L2-Schleifen. Der zentrale Unterschied: In gut designten MLAG-Topologien soll STP auf den Uplinks möglichst wenig „arbeiten“, weil die redundanten Pfade durch Bündelung kontrolliert sind.

STP als Safety-Net: aktiv lassen, aber stabil konfigurieren (Root-Placement, Guardrails), statt es als primären Redundanzmechanismus zu nutzen.
Edge-Schutz: BPDU Guard auf Endgeräteports verhindert, dass unerwartete Switches Loops einbringen.
Dokumentierte Root-Strategie: auch in MLAG-Designs muss klar sein, wer Root ist und warum.

Für Bridging- und STP-Grundlagen ist IEEE 802.1D eine hilfreiche konzeptionelle Referenz.

Mitigation-Techniken gegen typische Incidents: Von MAC-Flaps bis Blackholing

Wenn LACP/MLAG Probleme macht, zeigen sich die Symptome häufig indirekt: „Nur manche VLANs sind kaputt“, „nur manche Server verlieren Pakete“, „es gibt Latenzspitzen“ oder „Traffic ist asymmetrisch“. Folgende Mitigations haben sich im Betrieb bewährt:

Konfigdrift verhindern: Templates und Validierung, die VLAN-Listen, MTU, LACP-Parameter und Portrollen auf beiden Peers vergleichen.
Peer-Link Monitoring: Auslastung, Drops, LACP-Health des Peer-Link-LAG, plus Alerts auf ungewöhnlichen Traffic-Anstieg.
MAC-Flapping Alarme: MAC-Moves zwischen MLAG-Peers sind ein starkes Warnsignal; korrelieren Sie sie mit Changes.
Storm Control und Rate-Limits: begrenzen, wie stark ein Fehler sich ausbreiten kann (Broadcast/Unknown-Unicast/Multicast).
Min-Links und klare Degrade-Policies: definieren, wann ein Bündel „nicht mehr gut genug“ ist.
Runbooks für Split-Brain: klare Anweisungen, wie bei Peer-Link-/Keepalive-Problemen zu handeln ist, um Loops zu vermeiden.

Designentscheidungen im Data Center: MLAG vs. EVPN-Multi-Homing

In modernen Fabrics wird MLAG häufig als „klassische“ aktive/aktive Anbindung verwendet, während EVPN-basierte Designs Multi-Homing über eine Control Plane abbilden können. Beide Ansätze können stabil sein, aber sie haben unterschiedliche Trade-offs: MLAG ist oft einfacher am Rand (Server/Access) und sehr verbreitet, EVPN skaliert in großen Umgebungen häufig sauberer, wenn ohnehin eine Fabric-Architektur eingesetzt wird. Relevant ist hier vor allem, dass Sie nicht „Technologien mischen“, ohne Failure-Stories zu verstehen: Wenn MLAG am Edge eingesetzt wird, sollte die Interaktion mit Underlay/Overlay, STP-Safety-Net und Routing klar dokumentiert sein.

Als technische Referenz für EVPN eignet sich RFC 7432 (EVPN), insbesondere für ein Verständnis von Control-Plane-basiertem Learning und Multi-Homing-Konzepten.

Checkliste: LACP & MLAG stabil standardisieren

Portrollen definieren und templatisieren: Server, Access-Uplink, Peer-Link, Keepalive, Upstream – keine „Sonderfälle“ ohne Review.
Symmetrie erzwingen: identische VLAN-Listen, Native VLAN, MTU, QoS, LACP-Parameter auf beiden MLAG-Peers.
Peer-Link richtig dimensionieren: als LAG, redundant, überwacht; klare Schwellen für Auslastung und Drops.
Guardrails aktivieren: Storm Control, BPDU Guard (Edge), MAC-Limits, Loop-Protection passend zur Umgebung.
Min-Links definieren: kritische Bündel dürfen nicht „halb kaputt“ weiterlaufen.
Monitoring auf LACP/MLAG-Signale ausrichten: LACP-Status, Member-Changes, Peer-Link-Health, MAC-Flaps, BUM-Raten.
Runbooks für Failure-Modes: Peer-Link down, Keepalive down, Split-Brain-Indikatoren – mit klarer Reihenfolge der Maßnahmen.

Outbound-Links für vertiefende Referenzen

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.