Interface Health prüfen ist eine der wichtigsten Routineaufgaben im NOC und im Netzwerkbetrieb, weil die meisten Störungen sich zuerst an einem einzelnen Port zeigen: Link-Flaps, steigende CRC-/Input-Errors, Drops durch Queueing, optische Degradation, Speed-/Duplex-Probleme oder ein schleichender Hardwarefehler. Gleichzeitig ist „Interface Health“ mehr als nur „Link up“. Sie brauchen eine systematische Command-Checkliste, die schnell Antworten liefert: Ist der physische Link stabil? Gibt es Fehler auf Layer 1/2? Gibt es Drops durch Überlast oder Policers? Stimmen Speed, Duplex und Autonegotiation auf beiden Seiten? Sind Optikwerte (DOM/DDM) plausibel und im erwarteten Bereich? Und: Seit wann passiert das, also wie sieht der Verlauf aus? Dieser Artikel liefert eine praxistaugliche Command-Checkliste für Cisco, Juniper und MikroTik, inklusive Interpretationshinweisen, damit Sie nicht nur Zähler auslesen, sondern die Signale richtig einordnen. Ziel ist ein reproduzierbarer Ablauf: In wenigen Minuten erkennen Sie, ob es sich eher um ein physisches Problem, ein Kapazitäts-/Queueing-Thema, eine Fehlkonfiguration oder eine Gegenstellenstörung handelt, und Sie können das Ticket mit belastbaren Daten an Field Team, Vendor oder Engineering übergeben.
Grundprinzip: Interface Health immer als Kombination aus Status, Fehlern und Verlauf prüfen
Unabhängig vom Hersteller sollten Sie Interface Health immer in drei Ebenen prüfen. Ebene 1 ist der Status: administrativ up/down, operativ up/down, Speed, Duplex, Autonegotiation, MTU und (falls relevant) LACP/Bundle-Mitgliedschaft. Ebene 2 sind die Fehler: CRC/FCS und ähnliche „Frame Integrity“-Fehler, Input/Output Errors, Drops/Discards, Queue Drops sowie (bei Optik) DOM/DDM. Ebene 3 ist der Verlauf: Zählerstände allein sind wenig aussagekräftig; entscheidend ist die Rate und die Korrelation mit Events (Change, Lastspitzen, Temperatur, Patcharbeiten). Wenn Sie diese Ebenen konsequent abarbeiten, vermeiden Sie typische Fehlinterpretationen wie „CRC = Overload“ oder „hohe Auslastung = kaputter Link“.
Raten statt absolute Zähler nutzen
Im Ticket ist eine ErrorRate (z. B. CRC pro Minute) deutlich wertvoller als „CRC = 123456“, weil sie den aktuellen Zustand beschreibt und Vergleiche ermöglicht.
Was „gesund“ typischerweise bedeutet: schnelle Plausibilitätschecks
Bevor Sie in tiefe Diagnostik gehen, lohnt ein kurzer Plausibilitätsrahmen. Ein Interface ist im Normalbetrieb meist „gesund“, wenn der Link stabil ist (keine Flaps), Speed/Duplex erwartungsgemäß sind, keine oder nur sehr geringe ErrorRates auftreten, Drops nicht wachsen (oder nur im erwarteten Kontext), und optische Werte (falls vorhanden) stabil zur Baseline passen. Wenn eines dieser Signale aus dem Rahmen fällt, ist das Ihr Startpunkt.
- Link-Stabilität: „Last link flapped“-Hinweise, Link-Up/Down-Events, Log-Meldungen.
- Speed/Duplex: beidseitig konsistent; bei Kupfer besonders auf Autonegotiation achten.
- CRC/FCS: steigende Rate deutet häufig auf L1/L2-Qualität (Kabel, Optik, Interferenzen, Mismatch).
- Drops/Discards: häufig Queueing, Überlast, Policer oder QoS-Klassenproblem.
- Optik (DOM/DDM): Rx nahe RxMin oder driftende Rx-Werte sind Frühindikatoren.
Cisco: Command-Checkliste für Interface Health
Cisco-Umgebungen sind oft heterogen (IOS, IOS XE, NX-OS, ggf. IOS XR). Die Basislogik bleibt gleich: Sie starten mit Interface-Status und Zählern, prüfen dann Fehlerarten, Queueing/Drops und – bei Glasfaser – Transceiver- und DOM-Werte. Cisco stellt hierfür bewährte Troubleshooting-Übersichten bereit, zum Beispiel in der TechNote „Troubleshoot Switch Port and Interface Problems“: Cisco Troubleshooting zu Switch-Port- und Interface-Problemen.
Status und Basisdaten (Cisco)
- Interface-Status und Kerndaten: „show interfaces <interface>“ (Status, Speed/Duplex, MTU, Last-Input/Output, „last link flapped“, Error-Counter, Drops).
- Kurzübersicht über viele Ports: „show interface status“ (besonders auf Switches hilfreich).
- Administrativer Zustand: „show running-config interface <interface>“ (shutdown, speed/duplex, mtu, service-policy, storm-control).
- Log-Korrelation: „show logging | include <interface>“ (Link flaps, errdisable, SFP-Meldungen).
Fehler und Counter, die wirklich zählen (Cisco)
Bei Cisco ist es wichtig, die Art des Fehlers zu verstehen. CRC/FCS, runts/giants, alignment errors und ähnliche Counter sprechen eher für L1/L2-Probleme. Overrun/ignored/no buffer können eher auf Überlast/Buffer-Pressure hindeuten. Als Einstieg zur Interpretation von Counter-Ausgaben ist die Cisco-Übersicht zu Interface-Countern hilfreich, siehe ebenfalls die oben verlinkte Cisco TechNote.
- Fehlerfokussierte Ansicht (je nach Plattform): „show interfaces counters errors“ oder „show interfaces counters error“ (Switch-abhängig).
- Fehlerdetails am Interface: „show interfaces <interface>“ (CRC, frame, overrun, ignored, input errors, output errors, collisions bei alten Medien).
- Vergleich der Gegenseite: gleichen Check auf dem Nachbargerät ausführen (asymmetrische Fehler helfen bei der Lokalisierung).
Queueing, Drops, Policer und QoS (Cisco)
Drops sind häufig das stärkste Overload-Signal. Prüfen Sie deshalb immer, ob Discards/Output Drops steigen und ob eine Policy die Ursache ist.
- Interface-Discards/Drops: im Output von „show interfaces <interface>“ auf „output drops“, „input queue drops“ und ähnliche Felder achten.
- QoS/Policies am Interface: „show policy-map interface <interface>“ (Drops pro Klasse, Policers/Shapers).
- Platform-spezifische Queue-Infos: je nach Modell „show queueing interface <interface>“ oder ASIC-spezifische Befehle (hier sind Plattform-Runbooks sinnvoll).
Transceiver, DOM/DDM und Optikwerte (Cisco)
Bei Glasfaserlinks gehört DOM/DDM in jede Health-Prüfung. Damit erkennen Sie Overpower/Underpower, Drift und Temperaturprobleme früh. Eine allgemeine Einführung in Digital Optical Monitoring bietet Cisco hier: Cisco Knowledge Base zu Digital Optical Monitoring (DOM).
- Transceiver-Inventar: „show inventory“ (Modul erkannt, Seriennummer/Part Number).
- Optikdetails (NX-OS-Beispiel): „show interface transceiver details“ (Typ, Vendor, DOM-Werte, je nach Plattform). Für NX-OS gibt es entsprechende Konfigurations-/Referenzdokumente, z. B. in Cisco Nexus Interfaces Guides.
- DOM-Werte im Kontext: Rx/Tx-Power, Laser Bias, Temperatur, Spannung; Abgleich mit Baseline und mit „RxMin/RxMax“ laut Transceiver-Spezifikation.
Schnelle Cisco-Interpretationsregeln für Tickets
- CRC steigt, Drops nicht: eher physisch (Kabel/Optik/Stecker/Mismatch) als Kapazität.
- Drops steigen, CRC nicht: eher Queueing/Policer/QoS/Überlast als physisch.
- DOM driftet: früh Field-Team-Hygiene (Reinigung, Patchkette prüfen) oder Vendor-Eskalation vorbereiten.
- Fehler nur auf einer Seite: Lokalität wahrscheinlich (Port/Optik/Ende A) – aber Patchkette nie ausschließen.
Juniper (Junos): Command-Checkliste für Interface Health
In Junos sind „show interfaces extensive“ und „show interfaces statistics“ die zentralen Werkzeuge, um Status, Fehler und Drops konsistent zu erfassen. Juniper dokumentiert „show interfaces extensive“ sehr detailliert, inklusive Syntax und Output-Feldern: Juniper Doku: show interfaces extensive. Für Statistikansichten und Zähler bietet Juniper zudem „show interfaces statistics“: Juniper Doku: show interfaces statistics.
Status und Basisdaten (Junos)
- Detailansicht für einen Port: „show interfaces <interface> extensive“ (administrativ/operativ, Speed, Fehler, Drops, Queueing-Felder je nach Plattform, Link-Informationen).
- Statistikfokus: „show interfaces statistics <interface>“ (Counter-Übersicht, für viele Auswertungen kompakter).
- Log-Korrelation: „show log messages | match <interface>“ (oder je nach Logging-Setup) für Link-Events.
Input/Output Errors korrekt einordnen (Junos)
Juniper unterscheidet in vielen Plattformen sauber zwischen Fehlern durch Korruption (CRC/Alignment/PCS/FEC) und Drops durch Queueing/RED. Eine hilfreiche Erklärung zu „input errors“ und „output errors“ im Kontext von „show interface … extensive“ bietet Juniper im Support-Artikel: Juniper Support: Bedeutung von input/output errors. Diese Unterscheidung ist wichtig, weil sie direkt die Eskalationsrichtung beeinflusst (physisch vs. Überlast/Queueing).
- Korruptionsnahe Fehler: CRC, Alignment, PCS/FEC (spricht häufig für L1/L2-Themen).
- Drops am Input: Input-Queue-Drops oder RED/ASIC-Drops (spricht eher für Überlast oder Burst-Pattern).
- Asymmetrie prüfen: Fehler nur auf einer Seite sind besonders wertvoll für die Lokalisierung.
Live-Beobachtung bei sporadischen Fehlern (Junos)
Wenn ein Fehler sporadisch auftritt, helfen Live-Monitoring-Befehle. Juniper bietet dafür unter anderem „monitor interface error“, das Header-/Fehlerdetails an Interfaces ausgeben kann (je nach Junos-Version und Plattform): Juniper Doku: monitor interface error.
- Fehler live beobachten: „monitor interface error“ (Optionen je nach Bedarf einschränken).
- Trend im NOC dokumentieren: Zeitfenster und ErrorRate festhalten, statt nur Momentaufnahme.
Optik/Transceiver und DOM (Junos)
Je nach Plattform und Transceiver können Sie in Junos optische Werte und Transceiver-Informationen auslesen. Die konkreten Befehle variieren nach Gerätelinie (MX, QFX, EX, SRX). Operativ gilt: Transceiver-Typ, Vendor, Seriennummer und optische Werte sollten im Ticket stehen, wenn Sie physische Degradation vermuten. Wenn Ihre Umgebung stark standardisiert ist, lohnt ein internes Runbook mit den genauen Befehlen pro Plattformfamilie.
- Transceiver-Infos: je nach Plattform Befehle zur Optik- und Inventarprüfung nutzen (Vendor/PN/SN, DOM-Werte).
- Baseline nutzen: Rx/Tx-Werte gegen historische Baseline oder „bekannt gut“ vergleichen.
- Drift priorisieren: schleichende Rx-Abnahme ist häufig ein Frühindikator für Verschmutzung, Biegung oder schlechten Stecker.
MikroTik (RouterOS): Command-Checkliste für Interface Health
MikroTik wird in NOC-Umgebungen häufig als Edge-, Access- oder Aggregationskomponente eingesetzt. Für Interface Health sind in RouterOS vor allem drei Bereiche relevant: (1) Link-Status, Speed, Autonegotiation und Duplex, (2) Interface-Statistiken und Error Counter, (3) Transceiver/Optikwerte bei SFP/SFP+/SFP28/QSFP. MikroTik dokumentiert Ethernet-Statistiken und Diagnosefunktionen in der RouterOS-Dokumentation, zum Beispiel hier: MikroTik RouterOS Doku: Ethernet sowie für Counter-Ausgaben und Traffic-Monitoring hier: MikroTik RouterOS Doku: Interface stats und monitor-traffic.
Status, Speed, Autonegotiation (RouterOS)
- Ethernet-Status und Link-Parameter: „/interface/ethernet/print detail“ (zeigt u. a. Auto-Negotiation, Geschwindigkeit, Duplex, Advertisements; je nach Version/Hardware).
- Link-Monitoring am Port: „/interface/ethernet/monitor <interface>“ (live Anzeige von Link-Parametern; nützlich bei Flaps oder Aushandlungsproblemen).
- Konfiguration prüfen: „/interface/ethernet/set <interface> …“ nur im Change-Kontext; im Troubleshooting zunächst lesen und dokumentieren.
Counter und Traffic: Health über Statistik und Verlauf (RouterOS)
- Interface-Counter ausgeben: „/interface print stats“ oder „/interface print stats-detail“ (RX/TX-Pakete, Bytes, Drops/Errors je nach Interface-Typ).
- Traffic in Echtzeit: „/interface monitor-traffic <interface>“ (Ratenanzeige; gut zur Korrelation mit Drops/Fehlern und zur Erkennung von Burst-Verhalten).
- Link-Down-Historie: falls im Output verfügbar, Link-Down-Zähler und Events dokumentieren; zusätzlich Logs prüfen.
SFP/Optik bei MikroTik: Transceiver-Diagnose nutzen
Bei SFP-basierten Links können Sie in RouterOS Transceiver-Informationen und Diagnosewerte auslesen (Hardware- und Version-abhängig). Für NOC-Zwecke sollten Sie mindestens Transceiver-Typ, Vendor, und – wenn verfügbar – DOM-Werte (Tx/Rx, Temperatur) dokumentieren, wenn Sie physische Degradation oder Inkompatibilität vermuten.
- Transceiver-Infos und Diagnose: in den Ethernet/SFP-Ansichten der RouterOS-Doku beschrieben; nutzen Sie die jeweiligen Diagnose-/Monitor-Ausgaben pro Interface.
- Baseline etablieren: Einmal „bekannt gut“ erfassen, später Drift vergleichen.
- Inkompatibilitäten erkennen: Link kommt hoch, aber wird instabil oder zeigt Errors; Vendor-Mix kann eine Rolle spielen.
Herstellerübergreifende Quick-Checks: was Sie immer ins Ticket schreiben sollten
Eine gute Interface-Health-Prüfung endet nicht mit „Befehl ausgeführt“, sondern mit verwertbaren Daten im Ticket. Damit reduzieren Sie Rückfragen, beschleunigen Eskalationen und vermeiden, dass Teams „nochmal von vorn“ anfangen. Die folgenden Punkte sind herstellerübergreifend die wichtigsten Ticket-Inhalte.
- Identifikation: Gerät, Interface, Gegenstelle (wenn bekannt), Rolle (Uplink/Access/Server/Interconnect).
- Status: admin/oper, Speed, Duplex, Autonegotiation, MTU.
- Link-Stabilität: Flap-Historie oder Log-Zeitstempel (wann, wie oft).
- Fehler als Rate: CRC/FCS/Input Errors pro Zeitfenster; nicht nur absolute Counter.
- Drops/Discards: ebenfalls als Rate; wenn QoS/Policy relevant: Drops pro Klasse.
- Optikwerte (falls Glas): Rx/Tx, Temperatur, Bias; Vergleich zur Baseline und Nähe zu Grenzwerten.
- Korrelation: Change-Events, Wartungsfenster, Patcharbeiten, Lastspitzen, Temperatur-/Stromereignisse.
Diagnosemuster: typische Kombinationen und die wahrscheinlichste Richtung
Damit Sie Overload-Signale richtig lesen, hilft ein einfaches Mapping von Muster zu Richtung. Diese Muster sind bewusst herstellerneutral formuliert und funktionieren in Cisco-, Juniper- und MikroTik-Umgebungen gleichermaßen.
- CRC/FCS steigt, Drops nicht: hohe Wahrscheinlichkeit für physisches Problem (Kabel/Stecker/Optik/Interferenz/Mismatch). Nächste Schritte: Patchkette prüfen, Reinigung bei Glasfaser, Gegenseite vergleichen, ggf. Field Team.
- Drops/Discards steigen, CRC nicht: Queueing/Überlast/Policy wahrscheinlich. Nächste Schritte: QoS/Policer prüfen, Traffic-Pattern (Microbursts) analysieren, Kapazität und Egress-Engpässe bewerten.
- Link flapped ohne klare Lastkorrelation: physisch oder Aushandlung/Portprofil. Nächste Schritte: Autonegotiation/Speed/duplex beidseitig prüfen, SFP-Sitz und Patch prüfen, Logs korrelieren.
- DOM-Rx driftet langsam nach unten: Degradation in der optischen Strecke wahrscheinlich. Nächste Schritte: Reinigung, Steckverbindungen, Biegeradien, Patchpanel, ggf. OTDR/Field/Vendor-Eskalation.
- Fehler nur auf einer Seite sichtbar: Lokalisierung möglich, aber nicht blind tauschen. Nächste Schritte: Gegenstelle prüfen, Transceiver/Port tauschen (wenn SOP vorhanden), Patchkette validieren.
Praktische „Minimal-Checkliste“ pro Hersteller: in 5 Minuten zur ersten Diagnose
Wenn Sie im Incident schnell sein müssen, hilft eine minimalistische Reihenfolge. Diese Reihenfolge ist bewusst so gewählt, dass sie die häufigsten Ursachen abdeckt und dabei wenig Risiko erzeugt (nur read-only).
Cisco: Minimalfolge (read-only)
- „show interfaces <interface>“ (Status, Speed/Duplex, CRC/Input/Output Errors, Drops, „last link flapped“)
- „show interface status“ (wenn Switch, Überblick und Zustand)
- „show logging | include <interface>“ (Link-/SFP-/errdisable-Events)
- „show policy-map interface <interface>“ (falls Drops/QoS-Verdacht)
- „show inventory“ und transceiver-/DOM-Befehle (falls Glasfaser/Optik-Verdacht; DOM-Werte dokumentieren)
Juniper: Minimalfolge (read-only)
- „show interfaces <interface> extensive“ (Status, Errors, Drops, Hinweise auf Queueing)
- „show interfaces statistics <interface>“ (kompakte Counter-Sicht für Ratenberechnung)
- Log-Check passend zur Umgebung (Link-Events korrelieren)
- Optional „monitor interface error“ bei sporadischen Header-/Fehlerereignissen
- Transceiver/Optik-Ausgaben je nach Plattformfamilie (DOM-Werte, Vendor, Typ)
MikroTik: Minimalfolge (read-only)
- „/interface/ethernet/print detail“ (Link-Parameter, Autonegotiation, Speed/Duplex-Kontext)
- „/interface/ethernet/monitor <interface>“ (Live-Linkparameter, hilfreich bei Flaps)
- „/interface print stats“ oder „/interface print stats-detail“ (Counter; Grundlage für Rates)
- „/interface monitor-traffic <interface>“ (Traffic-Raten; Korrelation mit Drops/Fehlern)
- SFP/Optik-Diagnose gemäß Hardware/RouterOS (Transceiver-Daten und – wenn verfügbar – DOM-Werte dokumentieren)
Dokumentationspraxis: So wird die Command-Checkliste NOC-tauglich
Eine Command-Checkliste wirkt erst dann nachhaltig, wenn sie als SOP in Tickets, Runbooks und Übergaben verankert ist. Das bedeutet: gleiche Reihenfolge, gleiche Felder im Ticket, und ein klarer Standard, welche Outputs als Screenshot/Text übernommen werden müssen. Besonders wirksam ist ein Template, das die drei Ebenen Status–Fehler–Verlauf abfragt und eine kurze Hypothese erzwingt („physisch“, „Queueing“, „Mismatch“, „unklar“). Dadurch wird das Troubleshooting konsistent, auch über Schichten und Teams hinweg.
- Template-Felder: Statusdaten, ErrorRate, DropRate, DOM-Werte, Flap-Zeitstempel, Gegenstellenvergleich.
- Einheitliche Benennung: Interfaces exakt so schreiben wie im Gerät (keine Spitznamen).
- Beobachtungsfenster: mindestens zwei Zeitpunkte (t1/t2), um Raten zu berechnen.
- Stop-Regeln: Wenn Labels/Doku widersprüchlich sind, Field-Team mit Foto-/Belegen einschalten statt zu raten.
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.
