Layer-2 Diagramme: VLANs, Trunks, STP, MLAG/vPC verständlich zeichnen

Layer-2 Diagramme sind das wichtigste Werkzeug, um VLANs, Trunks, Spanning Tree (STP) und Multi-Chassis-LAG-Konzepte wie MLAG/vPC so abzubilden, dass sie im Betrieb wirklich verständlich sind. Genau hier scheitern viele Netzwerkpläne: Entweder zeigen sie nur physische Links (L1), ohne die Layer-2-Logik zu erklären – oder sie versuchen, jedes einzelne VLAN auf jede Leitung zu schreiben, bis das Diagramm unlesbar wird. Professionelle L2-Dokumentation braucht einen klaren Fokus: Broadcast-Domänen, Trunk-Grenzen, Redundanzmechanismen, Root-Placement und die Stellen, an denen Loops entstehen könnten. Wenn Sie Layer-2 sauber zeichnen, reduzieren Sie klassische Fehlerbilder wie VLAN-Mismatches, ungewollte STP-Blocks, MAC-Flaps, LACP-Inkonsistenzen und „mysteriöse“ Paketverluste. Dieser Artikel zeigt, wie Sie Layer-2 Diagramme strukturiert erstellen: welche Informationen hinein gehören, wie Sie VLANs gruppieren, wie Sie STP und MLAG/vPC lesbar machen und wie Ihre Diagramme als Living Documentation langfristig pflegbar bleiben.

Warum Layer-2 Diagramme so oft „Spaghetti“ werden

L2 ist ein Feld, in dem Detail schnell explodiert: jedes VLAN, jede Trunk-Liste, jede Port-Channel-ID, jedes STP-Role/State. Wer alles gleichzeitig darstellt, erhält eine Fläche voller Text, die niemand mehr scannt. Gleichzeitig sind reine L1-Diagramme für L2-Probleme wertlos: Sie zeigen Kabel, aber nicht, welche VLANs darüber laufen oder warum ein Link blocked ist. Der Ausweg ist ein bewusstes Schichtenmodell: Ein L2-Diagramm beantwortet eine klare Leitfrage – und nutzt abstrahierte Darstellungen statt VLAN-Listen.

• Leitfrage: „Welche Layer-2-Domänen und Trunk-Grenzen gibt es – und wie ist Loop-Prevention umgesetzt?“
• Abstraktion: VLANs als Gruppen/Tags statt als vollständige Listen.
• Grenzen sichtbar: wo endet L2? wo wird geroutet? (nur als Boundary-Hinweis, ohne L3-Details auszuwalzen)
• Redundanz erklären: STP-Root, MLAG/vPC, Port-Channels, Dual-Homing.

Was ein gutes L2-Diagramm immer zeigt und immer weglässt

Ein L2-Diagramm ist eine logische Sicht. Es muss nicht jede physische Patchstrecke enthalten, aber es muss die Topologie der Switches, die Trunk-Beziehungen und die L2-Mechanismen zeigen. Gleichzeitig sollten IP-Subnets, VRFs, BGP/OSPF-Details, Firewall-Policies und Service-Flows draußen bleiben. Sobald Sie L3/L4 vermischen, verliert das Diagramm seinen Zweck.

Muss enthalten

• Switch-Rollen (Access/Distribution/Core), ggf. Stack/Chassis/Virtual Switch
• Trunks und Port-Channels (LACP), mit eindeutigen IDs
• VLAN-Gruppen (z. B. „User“, „Voice“, „WLAN“, „IoT“, „Mgmt“) und wo sie erlaubt sind
• STP-Design: Root-Placement, zentrale L2-Grenzen, blocked Links (wenn statisch geplant)
• MLAG/vPC-Design: Peer-Link/Keepalive, Dual-Homed Links, Failure Domains

Sollte weglassen

• IP-Adresslisten, VRF- und Routingdetails
• Firewall-Regeln und Ports/Protokolle
• Patchpanel-Ports, Kabeltypen (das ist L1)
• Alle VLAN-IDs ausgeschrieben auf jedem Trunk (stattdessen gruppieren)

VLANs verständlich zeichnen: Gruppen, Tags und „Allowed-VLAN“-Logik

Der häufigste Fehler ist das Ausschreiben kompletter Allowed-VLAN-Listen (z. B. 20–30 VLANs pro Trunk). Das ist pflegeaufwendig und macht Diagramme unlesbar. Besser ist ein VLAN-Gruppenmodell: Sie definieren VLAN-Bundles (z. B. „CAMPUS-USER“, „CAMPUS-VOICE“, „CAMPUS-WIFI“, „CAMPUS-IOT“, „MGMT“) und referenzieren diese Bundles im Diagramm. Die genauen VLAN-IDs liegen dann in einer Source of Truth (IPAM/DCIM/CMDB) oder im VLAN-Katalog.

Bewährte Darstellungsmuster

• VLAN-Bundles: Ein Symbol/Label pro Bundle, nicht pro VLAN
• Trunk-Tags: „Trunk: CAMPUS-BUNDLE-A, MGMT“ statt „VLAN 10, 11, 12, 50, 60 …“
• Scope: pro Standort oder Gebäude ein eigenes Bundle-Set, falls nötig
• Ausnahmen: einzelne VLAN-Ausnahmen bewusst markieren („+VLAN 777 TEMP bis 2026-06-30“)

VLAN-Namens- und Nummernkonvention als Doku-Anker

• Semantische Namen: VLAN-USER, VLAN-VOICE, VLAN-WIFI-EMP, VLAN-WIFI-GUEST
• Nummernblöcke: reservierte Bereiche je Kategorie (z. B. 100–199 User, 200–299 Voice)
• Status: active/planned/deprecated, um „Zombie-VLANs“ sichtbar zu machen

Wenn Sie VLANs und Zuordnungen strukturiert führen möchten, lohnt sich eine technische Source of Truth wie NetBox; Einstieg: NetBox Dokumentation.

Trunks und Port-Channels: Lesbarkeit durch klare Linien- und Label-Regeln

Trunks sind das Rückgrat vieler L2-Topologien – und eine der häufigsten Fehlerquellen (native VLAN, Allowed-Liste, LACP-Mode, MTU-Mismatch). Im Diagramm sollten Trunks eindeutig identifizierbar sein: als Trunk-Link oder als Port-Channel mit mehreren physischen Mitgliedern.

Was auf Trunk-Links stehen sollte

• Link-Typ: Trunk oder Access (Access wird selten zwischen Switches genutzt, aber klar kennzeichnen)
• Port-Channel-ID: z. B. Po10, Port-Channel 1, ae1 (vendorabhängig)
• VLAN-Bundles: welche Gruppen sind erlaubt
• Native VLAN: nur wenn relevant (und besonders hervorheben, weil Fehlerpotenzial hoch ist)

Was Sie in separaten Artefakten halten sollten

• Mitgliedsinterfaces (Eth1/49, Eth1/50, …) – optional als Tooltip/Notiz, aber nicht als Textblock im Diagramm
• Detaillierte LACP-Settings – gehören in ein LLD oder in Konfig-Standards

STP verständlich zeichnen: Root-Placement, Rollen und Loop-Prevention

Spanning Tree ist für viele Teams „magisch“, weil der Algorithmus dynamisch ist. Ein gutes L2-Diagramm reduziert diese Magie, indem es das Designprinzip dokumentiert: Wo ist der Root? Welche Switches sind Primary/Secondary Root? Wo sind Blockings erwartet? Und welche Bereiche sind bewusst loopfrei durch MLAG/vPC oder durch L3-Grenzen?

Welche STP-Infos ins Diagramm gehören

• STP-Domain: pro Campus/Region (oder pro VRF/Segment, falls getrennt), kurz benennen
• Root Bridge: Primary und Secondary Root klar markieren
• Critical Links: Links, die bei Failure relevant sind (z. B. Uplinks Access→Distribution)
• Block-Intent: wenn bewusst geplant, blockende Links als gestrichelte Linie oder „blocked-by-design“ kennzeichnen

STP-Varianten korrekt benennen

Je nach Umgebung werden STP-Varianten genutzt (z. B. RSTP/MSTP). Dokumentieren Sie mindestens die Variante und die MST-Regionen/Instanzen, wenn MSTP im Einsatz ist. Als technische Referenz für Spanning Tree eignet sich die IEEE-Übersicht; ein Einstieg ist die IEEE 802.1D Referenzseite (STP) und bei moderneren Varianten die 802.1Q-Standards (MSTP/RSTP in der Praxis oft als Teil von 802.1Q beschrieben).

MLAG/vPC verständlich zeichnen: Dual-Homing ohne Verwirrung

MLAG (Multi-Chassis Link Aggregation) bzw. vPC (Virtual PortChannel, Cisco Nexus) sind häufige Bausteine, um Endgeräte (Server, Firewalls, Access-Switches) redundant an zwei Switches anzubinden, ohne dass STP unnötig blockt. Diagramme werden hier oft unlesbar, weil Peer-Link, Keepalive, vPC-Domäne und Memberlinks vermischt werden. Nutzen Sie eine klare Symbolik: Zwei Switches als „MLAG Pair“, ein Peer-Link als eigene Verbindung und die Dual-Homed Links als Port-Channel.

Was bei MLAG/vPC im Diagramm unbedingt sichtbar sein sollte

• Pair-Kennzeichnung: „MLAG Pair“, „vPC Domain X“ als Label am Switchpaar
• Peer-Link: eigene dicke Linie, klar beschriftet („Peer-Link Po1“)
• Keepalive: als dünne gestrichelte Linie, separat (nicht als Datenpfad)
• Dual-Homed Uplinks: als Port-Channel zum Downstream-Gerät (Server/Access-Switch)
• Failure Domain: Hinweis, welche Links/Devices bei Ausfall betroffen sind

Was Sie nicht ins MLAG/vPC-Diagramm pressen sollten

• Detaillierte vPC-Parameter, Timer, Konsistenzchecks – das gehört in LLD/Runbooks
• Alle VLAN-IDs auf jedem vPC – nutzen Sie VLAN-Bundles

Typische L2-Fehlerbilder: Diagramme so zeichnen, dass Troubleshooting schneller wird

Ein guter Test für Ihr L2-Diagramm ist: Hilft es bei den typischen Incidents? Wenn nicht, fehlt wahrscheinlich eine zentrale Information (Root, Trunk-Grenze, Bundle-Logik, MLAG-Intent). Die häufigsten L2-Probleme sind:

• VLAN-Mismatch: VLAN erlaubt auf Seite A, aber nicht auf Seite B
• Native VLAN Fehler: unerwartete Untagged Frames oder Leakage
• STP Blocking: Link ist blocked, aber Team weiß nicht, ob das „by design“ ist
• MAC Flapping: Loops oder inkonsistente LAG-Konfiguration
• MLAG/vPC Inkonsistenz: Peer-Link-Probleme, Keepalive-Ausfall, vPC-Suspend

Dokumentieren Sie im Diagramm die Stellen, an denen diese Fehler typischerweise auftreten, z. B. Access→Distribution Trunks, Edge-Peers, MLAG-Paare und Übergänge zu L3.

L2-Übergänge zu L3: Grenzen klar markieren

Viele Missverständnisse entstehen an L2/L3-Übergängen: Wo liegt das Default Gateway? Wo endet die Broadcast-Domäne? Wo findet Routing statt? Ein L2-Diagramm sollte diese Grenzen sichtbar machen, ohne ein L3-Diagramm zu werden. Nutzen Sie dafür Boundary-Symbole: „SVI/Gateway hier“ oder „L3 Boundary“ am Distribution/Core.

• SVI-Standort: z. B. „SVIs im Distribution Pair“ (ohne IPs)
• VRF-Hinweis: nur als Tag, falls mehrere VRFs existieren
• Routing-Geräte: als Rolle markieren (z. B. „L3 Core“)

Diagramm-Standards: Symbole, Linienarten, Farben und Metadaten

Layer-2 Diagramme werden teamweit nutzbar, wenn Sie Standards definieren. Diese müssen nicht komplex sein, aber verbindlich. Ein guter Standard sorgt dafür, dass jede Person ein Diagramm sofort lesen kann.

Minimaler Standard für L2-Diagramme

• Linienarten: solid = Datenpfad, gestrichelt = Keepalive/Control, dick = Port-Channel/Bundle
• Symbole: Switch-Rollen (Access/Dist/Core) als Badge, MLAG/vPC als Pair-Rahmen
• Farben: sparsam für Domänen (z. B. Campus, DC) oder für Trust Boundaries, nicht für Dekoration
• Metadaten: Owner, Last updated, Scope (Site/Building), Version
• Legende: einmal pro Diagrammset, damit neue Leser sofort starten

Living Documentation: L2-Diagramme aktuell halten ohne Overhead

Diagramme veralten, wenn sie nicht an Changes gekoppelt sind. Die pragmatische Lösung ist eine Definition of Done: Wenn ein Change VLAN-Bundles, Trunks, STP-Root-Placement oder MLAG/vPC betrifft, wird das L2-Diagramm aktualisiert. Zusätzlich helfen regelmäßige Stichproben-Reviews für kritische Standorte.

• Definition of Done: kein Change abgeschlossen ohne Diagramm-Update, wenn L2 betroffen ist
• Review-Zyklus: z. B. quartalsweise für Campus-Core/Edge, halbjährlich für Access-Layer
• Source of Truth: VLAN-Katalog und Gerätedaten zentral führen, Diagramm referenziert Bundles

Wenn Sie Change- und Knowledge-Management prozessorientiert strukturieren möchten, ist ITIL Best Practices ein hilfreicher Rahmen.

Pragmatischer Einstieg: Ein L2-Diagrammset in wenigen Tagen aufbauen

Sie müssen nicht mit jedem Access-Switch beginnen. Starten Sie mit den Bereichen, die die meisten Incidents erzeugen: Distribution/Core, MLAG/vPC-Paare, kritische Trunks und STP-Root-Placement. Danach ergänzen Sie Access-Blöcke als wiederverwendbare „Pods“ oder „Blocks“.

• Tag 1: Rollenmodell und VLAN-Bundles definieren (User/Voice/WiFi/IoT/Mgmt)
• Tag 2: Distribution/Core L2-Topologie zeichnen, STP Root Primary/Secondary markieren
• Tag 3: MLAG/vPC-Paare modellieren, Peer-Link/Keepalive sauber darstellen
• Tag 4+: Access-Blöcke als Templates, Sonderfälle bewusst als Ausnahmen markieren

Typische Fehler beim Zeichnen von L2 und wie Sie sie vermeiden

• VLAN-Listen auf jedem Trunk: unlesbar; Lösung: VLAN-Bundles + Referenz auf VLAN-Katalog.
• STP wird ignoriert: später „mysteriöse“ Blockings; Lösung: Root-Placement und Block-Intent dokumentieren.
• MLAG/vPC ohne Peer-Link/Keepalive: Verständnis fehlt; Lösung: Pair-Struktur sichtbar machen.
• Keine L2/L3-Grenze: falsche Troubleshooting-Pfade; Lösung: Boundary-Symbole für Routing-Grenzen.
• Keine Metadaten: niemand vertraut dem Diagramm; Lösung: Owner + Last updated verpflichtend.

Checkliste: Layer-2 Diagramme für VLANs, Trunks, STP und MLAG/vPC

• Das L2-Diagramm beantwortet die Leitfrage „L2-Domänen, Trunk-Grenzen und Loop-Prevention“
• VLANs werden als Gruppen/Bundles dargestellt, nicht als lange Allowed-Listen auf jedem Link
• Trunks und Port-Channels sind eindeutig beschriftet (Po-ID, Bundle-Name, Native VLAN falls relevant)
• STP-Design ist sichtbar (Root Primary/Secondary, Block-Intent, zentrale L2-Failure-Domains)
• MLAG/vPC ist als Pair modelliert (Peer-Link, Keepalive, Dual-Homing, Failure Domain)
• L2/L3-Grenzen sind markiert (SVI/Gateway-Standort als Hinweis, ohne IP-Details)
• Diagrammstandard existiert (Linienarten, Symbole, Legende, Metadaten)
• Source of Truth ist verlinkt (VLAN-Katalog, Device-Inventory), Diagramme duplizieren keine Stammdaten
• Definition of Done koppelt L2-Changes an Diagramm-Updates (Living Documentation)
• Outbound-Links verweisen auf Primärquellen (IEEE 802.1D/802.1Q, ITIL für Prozessrahmen, NetBox für SoT)

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.