Link-Dokumentation: Bandbreite, Medien, LACP/EtherChannel und Redundanz

Eine professionelle Link-Dokumentation ist in Unternehmensnetzwerken einer der größten Hebel für Stabilität, schnelle Fehlersuche und saubere Redundanz. Während Geräteinventar und VLAN-Listen in vielen Organisationen bereits existieren, fehlt oft genau das Bindeglied: die dokumentierte Verbindung zwischen den Geräten – also der Link. Ohne diese Information entstehen im Alltag typische Probleme: Uplinks werden verwechselt, Port-Channels werden falsch erweitert, Glasfaserstrecken sind unklar, Bandbreiten werden überschätzt, und Redundanz existiert nur „gefühlt“. Besonders kritisch wird es bei LACP/EtherChannel, bei Multi-Chassis-Designs (MLAG/vPC) und bei Standort- oder Rack-übergreifenden Verbindungen, wo ein einzelnes falsches Patchkabel plötzlich große Teile des Netzwerks beeinflusst. Dieser Leitfaden zeigt, wie Sie Links so dokumentieren, dass sie im Betrieb wirklich helfen: mit klaren Feldern für Bandbreite, Medium, LACP/EtherChannel, Endpunkte, Redundanzgruppen, Monitoring und Change-Historie – verständlich für Einsteiger, belastbar für Profis und direkt nutzbar für Unternehmen.

Warum Link-Dokumentation mehr bewirkt als zusätzliche Diagramme

Ein Diagramm kann einen Überblick geben – aber Links sind die „Faktenebene“ der Topologie. Ein Link ist nicht nur eine Linie zwischen zwei Switches, sondern eine Beziehung mit Eigenschaften: Kapazität, Medium, Bündelung, Zweck, Abhängigkeiten und Kritikalität. Im Incident ist genau diese Beziehung entscheidend: Wenn ein Uplink flapt, wollen Sie sofort wissen, ob es ein einzelner 10G-Link ist oder ein Port-Channel mit 2x10G, ob der Link zu einem Core-Switch führt oder zu einem Server, und ob es einen redundanten Pfad gibt.

• Faster Troubleshooting: Endpunkte, Rollen und Medien sind eindeutig, keine Sucharbeit am Rack.
• Sichere Redundanz: A/B-Pfade und Diversität werden sichtbar statt angenommen.
• Saubere Changes: Port-Channel-Erweiterungen, SFP-Wechsel und Umzüge sind planbar.
• Kapazitätsplanung: reale Bandbreite pro Pfad, Engpässe und Overbooking werden erkennbar.
• Audit und Übergaben: Abhängigkeiten sind nachvollziehbar, nicht „Wissen im Kopf“.

Grundprinzip: Ein Link ist ein eigenes Objekt – nicht nur ein Textfeld

Viele Teams dokumentieren Links als Freitext in Interface-Descriptions. Das ist hilfreich, aber nicht ausreichend, weil Beziehungen und Eigenschaften nicht strukturiert sind. Link-Dokumentation funktioniert am besten, wenn ein Link als eigener Datensatz existiert: Endpunkt A + Endpunkt B + Eigenschaften. Daraus lassen sich Topologieansichten und Reports ableiten, und Sie können prüfen, ob Redundanzgruppen wirklich getrennte Wege nutzen.

Die drei Ebenen, die Sie trennen sollten

• Physischer Link: Kabel/Medium/Transceiver zwischen Port A und Port B.
• Logischer Link: Port-Channel (LACP/EtherChannel), MLAG/vPC-Bündel, Routed Link.
• Pfad/Service: Redundanzpfad (A/B), WAN-/Transitpfade, kritische Serviceabhängigkeiten.

Welche Felder gehören in eine gute Link-Dokumentation?

Eine Link-Doku muss kurz genug sein, um gepflegt zu werden, aber vollständig genug, um im Incident zu helfen. Bewährt hat sich ein Kernset aus Pflichtfeldern plus Zusatzfelder für Highspeed, Glasfaser und Redundanz.

Pflichtfelder pro Link

• Link-ID: eindeutige Kennung (z. B. LNK-BER-000123) oder sprechender Name
• Endpunkt A: Gerät + Port (z. B. ber-sw-core-01 Te1/1/1)
• Endpunkt B: Gerät + Port (z. B. ber-sw-access-02 Te1/1/1)
• Rolle: uplink, downlink, interconnect, server, storage, ha, wan
• Medium: Kupfer, Glasfaser, DAC, AOC
• Bandbreite: 1G/10G/25G/40G/100G (ggf. nominal pro Mitglied)
• Status: aktiv, reserviert, außer Betrieb
• Standort/Rack: wenn relevant (z. B. RACK-BER-01 ↔ RACK-BER-02)
• Owner: verantwortliches Team
• Letzte Änderung: Datum + Ticket/Change-Referenz

Optionale Felder (bei kritischen Links sehr sinnvoll)

• Port-Channel-Zuordnung: Po-Interface (z. B. Po12) und Mitgliedschaft
• LACP-Modus: aktiv/passiv (oder „static“ bei EtherChannel ohne LACP)
• Transceiver-Typ: SR/LR/ER/CR (nur Typ, keine Secrets)
• Fasertyp: SM/MM, Stecker (LC/SC), Duplex/Simplex
• Kabellänge/Label: Kabel-ID (beide Enden identisch), Länge (hilft im Rack)
• MTU: abweichend (z. B. Storage/Overlay)
• Redundanzgruppe: Link-A/Link-B oder Path-A/Path-B
• Monitoring-KPI: Fehlerzähler, CRC, Flaps, Optikwerte (wenn verfügbar)

Bandbreite richtig dokumentieren: Nominal, effektiv und „wo ist der Flaschenhals?“

„10G Link“ ist nicht automatisch „10G nutzbar“. Dokumentieren Sie deshalb nicht nur die nominale Bandbreite, sondern auch den Kontext: Ist es ein einzelner Link oder Teil eines Bündels? Gibt es Overcommitment? Gibt es asymmetrische Pfade? Und wo endet der Pfad – beispielsweise an einem 1G-Access-Switch hinter einem 10G-Uplink?

Pragmatische Bandbreitenregeln

• Nominal: Geschwindigkeit pro physischem Port (z. B. 10G)
• Bündelkapazität: Summe der Member-Links (z. B. 2x10G = 20G nominal)
• Effektive Nutzung: hängt von Hashing/Flows ab (nicht jeder Flow bekommt 20G)
• Engpass markieren: wenn ein Pfad downstream/upstream kleiner ist

LACP-Bündel: Warum 2x10G nicht immer „20G für alles“ bedeutet

LACP verteilt Traffic typischerweise per Hash (z. B. Source/Destination MAC/IP/Port) auf Mitglieder. Ein einzelner großer Flow kann daher auf einem Link „kleben“ und nicht automatisch 20G nutzen. Dokumentieren Sie deshalb bei kritischen Links: Hashing-Policy (high-level), Erwartung (viele Flows vs. wenige große Flows) und ob das Bündel für Redundanz, Kapazität oder beides gedacht ist.

Medien dokumentieren: Kupfer, Glasfaser, DAC/AOC – was wirklich zählt

Viele Linkprobleme sind Medienprobleme: falscher Transceiver, falscher Fasertyp, zu lange Kupferstrecke, schlechte Patchkabel, beschädigte Glasfaser oder ungeeignete DACs. Eine gute Dokumentation hält fest, welches Medium verwendet wurde und welche Komponenten kritisch sind.

Kupfer (Twisted Pair)

• Kategorie: Cat5e/Cat6/Cat6A (wenn bekannt und relevant)
• Einsatz: typischerweise 1G/2,5G/5G/10G (abhängig von Umfeld)
• Hinweis: PoE-Relevanz bei AP/VoIP/Kameras dokumentieren

Glasfaser

• Fasertyp: Singlemode (SM) oder Multimode (MM)
• Transceiver: SR/LR/ER (Typ), Wellenlänge/Reach optional
• Patchfelder/Cassetten: Zwischenpunkte dokumentieren (Cross-Connects)
• Polarity: bei Problemen relevant, optional dokumentieren

DAC/AOC

• DAC: Direct Attach Copper für kurze Strecken, häufig im Rack
• AOC: Active Optical Cable für kurze bis mittlere Strecken
• Kompatibilität: Hersteller-/Codierungsthemen als Risiko/Notiz erfassen

Für strukturierte Verkabelung und Grundprinzipien wird in vielen Umgebungen ISO/IEC 11801 als Referenzrahmen herangezogen.

LACP/EtherChannel dokumentieren: Struktur, Member-Ports und Betriebsintention

Port-Channels sind häufig die kritischsten Links im Netzwerk, weil sie Core- und Distribution-Ebenen verbinden. Dokumentation muss hier zwingend zwischen der logischen Schnittstelle (Port-Channel) und den physischen Member-Links unterscheiden. Außerdem sollten Sie festhalten, ob LACP aktiv genutzt wird oder ob es sich um statisches Bundling handelt.

Port-Channel-Template (LLD)

• Port-Channel: Po12
• Endpunkte: ber-sw-core-01 Po12 ↔ ber-sw-access-02 Po12
• Member-Ports A: Te1/1/1, Te1/1/2
• Member-Ports B: Te1/1/1, Te1/1/2
• Modus: trunk oder routed
• Allowed VLANs: wenn trunk (Liste oder Profilreferenz)
• LACP: active/active oder active/passive (high-level)
• Zweck: Kapazität, Redundanz oder beides

Dokumentieren Sie das „Warum“

• Kapazität: Bündel dient zur Bandbreitenerhöhung
• Redundanz: Bündel dient primär zur Ausfallsicherheit
• Stabilität: Bündel dient zur Reduktion von STP-Änderungen/Flaps

Redundanz dokumentieren: Link-Redundanz ist nicht automatisch Pfad-Redundanz

Eine der häufigsten Fehleinschätzungen lautet: „Wir haben zwei Links, also sind wir redundant.“ In der Realität können zwei Links am gleichen Patchfeld, im gleichen Kabelkanal oder am gleichen Switchmodul hängen. Gute Link-Dokumentation beschreibt deshalb nicht nur „A und B“, sondern auch die Diversität: unterschiedliche Linecards, unterschiedliche Patchfelder, unterschiedliche Racks, idealerweise unterschiedliche Wege oder Stromkreise (je nach Kritikalität).

Redundanzfelder, die wirklich helfen

• Redundanzgruppe: z. B. UPLINK-A / UPLINK-B
• Diversitätsmerkmal: getrennte Patchfelder, getrennte Racks, getrennte Linecards
• Failure Domain: gemeinsamer Single Point (z. B. gleiche PDU, gleicher Kabelkanal) markieren
• Failover-Intention: aktiv/aktiv (ECMP/MLAG) vs. aktiv/passiv
• Testnachweis: wann wurde Failover zuletzt getestet?

STP/MLAG/vPC – Redundanzkonzepte nur high-level erfassen

Sie müssen keine vollständige Konfiguration dokumentieren, aber die Redundanzlogik sollte klar sein: Welche Switches bilden ein Paar? Gibt es MLAG/vPC? Ist der Link Teil eines Multi-Chassis-Port-Channels? Welche Links sind Peer-Links/Keepalives? Diese Informationen verhindern gefährliche Umbaufehler.

Link-Dokumentation in Diagrammen: Linien sind nur dann hilfreich, wenn sie beschriftet sind

Diagramme bleiben wichtig, aber ohne Linkdetails werden sie schnell zu „Linienkunst“. Best Practice ist, Links im Diagramm nur für die relevanten Ebenen zu beschriften: Bandbreite, Port-Channel, Provider/Circuit-ID (bei WAN) und Linkrolle. Details wie Transceiver-Typen gehören eher in die Linktabelle.

Diagrammregeln, die sich bewährt haben

• Beschriftung kritischer Links: „Po12 (2x10G)“ statt nur Linie
• Linienstile: durchgezogen = physisch, gestrichelt = logisch (Overlay/VPN)
• Legende: Linkrollen (uplink/ha/storage), Abkürzungen (Po, LACP)
• Version/Owner: direkt im Diagramm, damit Exporte nicht zur Schattenwahrheit werden

Für konsistente Symbolik werden häufig etablierte Icon-Sets genutzt, z. B. die Cisco Network Topology Icons.

Monitoring: Links überwachen ist mehr als „Interface up“

Ein Link kann „up“ sein und dennoch Probleme verursachen: CRC-Errors, Drops, optische Dämpfung, Flapping, Duplex-/Speed-Mismatches oder LACP-Inkonsistenzen. Dokumentieren Sie daher bei kritischen Links, welche KPIs überwacht werden und welche Schwellen Alarme auslösen. So wird Monitoring nachvollziehbar und Reaktionswege sind klar.

Wichtige Link-KPIs

• Link-Flaps: Anzahl in Zeitraum, korreliert mit Störungen
• Errors: CRC, FCS, Input/Output Errors
• Drops: Queue Drops, Congestion-Indikatoren
• Optikwerte: Rx/Tx Power (bei SFPs), wenn verfügbar
• LACP-Status: Member in Sync? Unbalanced Hashing?
• Durchsatz: Trends, Engpässe, Peak-Auslastung

Alarmierung dokumentieren

• Alarmname: lnk-ber-core-access-po12-errors
• Schwelle: z. B. > X CRC/min oder > Y Flaps/Tag
• Owner/On-Call: wer reagiert?
• Runbook-Link: Prüfpfad, typische Ursachen, Austauschprozess

Wie Sie Link-Dokumentation effizient aufbauen: Schritt-für-Schritt

Der häufigste Fehler ist, alle Links auf einmal dokumentieren zu wollen. Effektiver ist ein stufenweiser Ansatz: erst kritische Pfade, dann Breite. So entsteht früh Nutzen und die Dokumentation kann wachsen, ohne zu scheitern.

• Schritt 1: Linkrollen und Redundanzgruppen definieren (Uplink, HA, Storage, WAN)
• Schritt 2: Core/Distribution-Uplinks und Port-Channels erfassen
• Schritt 3: Server-/Hypervisor- und Storage-Links dokumentieren (inkl. MTU/Medium)
• Schritt 4: Standort- und Rack-übergreifende Links ergänzen (Diversität markieren)
• Schritt 5: Monitoring-Referenzen und KPI-Schwellen für kritische Links hinzufügen
• Schritt 6: Regelmäßige Hygiene: unnötige Trunk-VLANs, verwaiste Links, falsche Labels bereinigen

Tooling: Tabelle starten, strukturierte Systeme nutzen

Für kleine Umgebungen kann eine gut strukturierte Linktabelle reichen. Sobald jedoch viele Geräte, Port-Channels, Racks und Standorte beteiligt sind, lohnt sich ein System, das Beziehungen modellieren kann. Ein verbreiteter Ansatz ist ein IPAM/DCIM-System wie NetBox, das Geräte, Interfaces und Verbindungen strukturiert abbildet und als zentrale Wahrheit dienen kann.

Pragmatische Regel: Eine Quelle der Wahrheit

• Führende Quelle definieren: DCIM/IPAM oder zentrale Tabelle
• Diagramme als View: Diagramme referenzieren Link-IDs/Port-Channels, aber duplizieren nicht alle Details
• Versionierung: Änderungen nachvollziehbar halten (Ticket/Change-Verknüpfung)

Prozess: So bleibt Link-Dokumentation dauerhaft aktuell

Linkdokumentation driftet, wenn Umstecken und Erweiterungen ohne Prozess passieren. Die wirksamste Maßnahme ist ein Change-Gate: Jede Link-Änderung (Patchkabel, SFP, LACP-Änderung, Port-Channel-Erweiterung) erfordert ein Dokumentationsupdate als Abschlusskriterium. Ergänzen Sie Reviews und Stichproben, um Drift früh zu erkennen.

Definition of Done für Link-Changes

• Endpunkte und Port-Channel-Zuordnung aktualisiert
• Bandbreite/Medium/Transceiver-Typ (falls relevant) dokumentiert
• Redundanzgruppe und Diversität geprüft
• Monitoring-Checks und Alarme verifiziert
• Post-Check: Link up, Fehlerzähler stabil, LACP in Sync, Traffic ok

Review-Routine (praxisnah)

• Monatlich: Stichprobe kritischer Links (Core/Uplinks/HA) auf Doku vs. Realität
• Quartalsweise: Port-Channels, Redundanzgruppen und Diversität prüfen
• Halbjährlich: Medium-/Transceiver-Standards, Lifecycle und Engpassanalyse aktualisieren

Typische Fehler bei Link-Dokumentation – und wie Sie sie vermeiden

• Nur „Linien“ ohne Daten: Bandbreite, Rolle und Port-Channel fehlen
• Port-Channel ohne Memberliste: Umbauten brechen Redundanz
• „Zwei Links = redundant“: gemeinsame Failure Domains werden übersehen
• Medien unklar: falsche SFPs/Fasern führen zu instabilen Links
• Kein Monitoring-Kontext: Link ist „up“, aber Errors steigen unbemerkt
• Kein Prozess: Patchen ohne Change → Doku driftet sofort

Praxis-Template: Link-Eintrag, der im Betrieb hilft

• Link-ID: LNK-BER-000123
• A: ber-sw-core-01 Te1/1/1
• B: ber-sw-access-02 Te1/1/1
• Rolle: uplink
• Medium: Fiber MM, LC duplex
• Bandbreite: 10G
• Port-Channel: Po12 (Member 1/2), LACP active
• Redundanzgruppe: UPLINK-A
• Diversität: getrennte Linecards ja, getrennte Patchfelder ja
• Monitoring: CRC < 10/h, Flaps 0/Tag, Optikwerte überwacht
• Letzte Änderung: 2026-02-10 (CHG-12345)

Checkliste: Link-Dokumentation für Bandbreite, Medien, LACP/EtherChannel und Redundanz

• Links als eigene Objekte dokumentiert (Endpunkt A/B + Eigenschaften), nicht nur als Freitext
• Pflichtfelder eingeführt (Rolle, Medium, Bandbreite, Status, Owner, Change-Referenz)
• Port-Channels vollständig erfasst (Po-Interface + Member-Ports + LACP-Modus + Zweck)
• Bandbreite korrekt interpretiert (nominal vs. Bündel, Hashing-Erwartung bei LACP)
• Medien standardisiert dokumentiert (Kupfer/SM/MM/DAC/AOC, Transceiver-Typ bei Highspeed)
• Redundanzgruppen und Diversität sichtbar gemacht (Failure Domains markiert, A/B getrennt)
• Monitoring-Regeln definiert (Flaps, Errors, Drops, Optikwerte, LACP-Sync) inkl. Alarmierung
• Diagramme als ergänzende Views genutzt (beschriftete kritische Links, Version/Owner im Bild)
• Eine führende Quelle definiert (keine Schattenlisten), Verlinkung zu Inventar/Rack/Standortdoku
• Change-Gate und Review-Zyklen etabliert, damit Link-Doku dauerhaft aktuell bleibt

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.