18.8 Wichtige Cisco-Befehle zur Netzwerk-Fehlersuche

Bei der Netzwerk-Fehlersuche in Cisco-Umgebungen entscheidet nicht nur Erfahrung über den Erfolg, sondern vor allem die Fähigkeit, die richtigen Befehle in der richtigen Reihenfolge einzusetzen. Router, Switches und Layer-3-Switches liefern über die Cisco CLI eine große Menge an Zustandsdaten, doch ohne systematische Auswahl entsteht schnell Informationsrauschen statt Klarheit. Wichtige Cisco-Befehle zur Netzwerk-Fehlersuche helfen dabei, physische Probleme, VLAN-Fehler, Routing-Störungen, ACL-Blockaden, Interface-Probleme und Layer-2-Anomalien gezielt einzugrenzen. Wer die wichtigsten Show-, Ping-, Trace- und Debug-Kommandos beherrscht, kann Störungen schneller lokalisieren, Auswirkungen besser bewerten und fundierter entscheiden, ob die Ursache am Endgerät, am Access-Layer, am Distribution-Layer oder im Routing-Kern liegt.

Warum Cisco-Befehle für Troubleshooting unverzichtbar sind

In produktiven Netzwerken ist Fehlersuche keine Frage einzelner Zufallsbefunde. Ein Anwender meldet beispielsweise „kein Netzwerk“, doch die tatsächliche Ursache kann von einem administrativ deaktivierten Interface über ein falsches VLAN bis hin zu einer fehlerhaften Route oder Access Control List reichen. Cisco-Geräte stellen genau für diese Analyse differenzierte CLI-Befehle bereit, mit denen sich Betriebszustände, Konfigurationen und Datenpfade in Echtzeit nachvollziehen lassen.

• Show-Befehle liefern Ist-Zustände von Interfaces, VLANs, Routing und Protokollen.
• Testbefehle wie ping und traceroute prüfen Erreichbarkeit und Pfadverhalten.
• Tabellen wie ARP, MAC und Routing zeigen, wie das Gerät Nachbarn und Ziele aktuell kennt.
• Debug-Befehle helfen bei tiefergehender Analyse, müssen aber kontrolliert eingesetzt werden.

Entscheidend ist, nicht wahllos Befehle auszuführen, sondern entlang eines strukturierten Modells zu arbeiten: zuerst physische Konnektivität, dann Layer 2, danach Layer 3, schließlich Dienste wie DHCP, DNS, NAT oder Routing-Protokolle.

Grundlegende Befehle zur ersten Bestandsaufnahme

Zu Beginn jeder Fehlersuche steht die Frage: Welchen Zustand hat das Gerät aktuell? Dafür eignen sich einige Standardbefehle, die fast immer zu den ersten Schritten gehören.

Geräte- und Interface-Status prüfen

show ip interface brief
show interfaces
show interfaces status
show running-config
show version
show logging

Besonders wichtig ist show ip interface brief. Dieser Befehl liefert schnell eine kompakte Übersicht über alle Interfaces, deren IP-Adressen und ihren administrativen beziehungsweise operativen Zustand.

• up/up bedeutet: Interface ist administrativ aktiv und physisch betriebsbereit.
• administratively down zeigt meist ein per Konfiguration deaktiviertes Interface.
• up/down weist häufig auf ein Layer-1- oder Gegenstellenproblem hin.
• down/down spricht oft für physische Trennung, defektes Kabel oder ausgeschaltete Gegenstelle.

show interfaces geht deutlich tiefer und zeigt Fehlerzähler, Bandbreite, Duplex, CRC-Fehler, Input Errors, Output Drops und Queue-Informationen. Gerade bei Performance-Problemen oder physischen Störungen ist dieser Befehl zentral.

Wichtige Anzeichen in Interface-Ausgaben

• Hohe CRC-Werte deuten oft auf Layer-1-Probleme wie Kabel- oder Portfehler hin.
• Input Errors können auf schlechte Leitungen, Duplex-Mismatch oder Störungen im Empfangspfad hinweisen.
• Output Drops sprechen häufig für Überlast, Queue-Probleme oder Engpässe.
• Ein stark abweichender Lastwert kann auf Broadcast-Stürme oder ungewöhnlichen Traffic hinweisen.

Layer-2-Fehlersuche auf Cisco-Switches

Viele Netzwerkprobleme entstehen im Switching-Bereich. Falsche VLAN-Zuordnungen, Trunk-Fehler oder fehlende MAC-Learnings führen dazu, dass Clients keine Gateways erreichen, DHCP nicht funktioniert oder nur Teile der Kommunikation ausfallen.

VLANs und Portzuordnung analysieren

show vlan brief
show interfaces switchport
show interfaces trunk
show mac address-table

Mit show vlan brief lässt sich prüfen, welche VLANs auf dem Switch existieren und welchen Access-Ports sie zugeordnet sind. Wenn ein Client im falschen VLAN landet, ist das hier oft sofort sichtbar.

• Ist das Ziel-VLAN überhaupt auf dem Switch vorhanden?
• Ist der betroffene Access-Port dem richtigen VLAN zugeordnet?
• Stimmt die Trunk-Freigabe zwischen den Switches?
• Wird die MAC-Adresse des Endgeräts am erwarteten Port gelernt?

show interfaces trunk ist besonders wichtig, wenn VLANs zwischen Switches transportiert werden. Fehlt ein VLAN auf dem Trunk, wirkt es für Hosts so, als sei das Netzwerk oder Gateway nicht erreichbar, obwohl die physische Verbindung intakt ist.

MAC-Adress-Tabelle gezielt nutzen

show mac address-table
show mac address-table dynamic
show mac address-table address 0011.2233.4455

Die MAC-Adress-Tabelle zeigt, ob ein Switch Frames eines Endgeräts überhaupt empfängt und an welchem Port die Quelle gelernt wurde. Wenn eine MAC-Adresse nicht erscheint, liegt das Problem oft vor dem Switchport oder am Endgerät selbst. Wenn sie an einem unerwarteten Port erscheint, deutet das auf Verkabelungs- oder Topologiefehler hin.

Spanning Tree bei Layer-2-Problemen prüfen

show spanning-tree
show spanning-tree vlan 10
show spanning-tree interface gigabitEthernet1/0/10 detail

Spanning Tree ist für schleifenfreie Layer-2-Topologien essenziell. Ein blockierter oder inkonsistenter Port kann dazu führen, dass Konnektivität nur teilweise oder gar nicht funktioniert.

• Ist der erwartete Uplink forwarding oder blocking?
• Gab es Topology Changes in kurzer Folge?
• Steht der Root Bridge an der gewünschten Stelle im Netz?

Häufige Wechsel im Spanning-Tree-Zustand deuten auf Instabilität, Schleifen oder problematische Access-Geräte hin.

Layer-3-Fehlersuche: IP, ARP und Routing prüfen

Sobald Layer 2 plausibel erscheint, folgt die Layer-3-Analyse. Hier geht es um IP-Adressierung, Erreichbarkeit von Gateways und die Frage, ob das Cisco-Gerät den korrekten Weg zum Ziel kennt.

IP-Konfiguration und SVI-Zustand prüfen

show ip interface brief
show running-config interface vlan 10
show interfaces vlan 10

Auf Layer-3-Switches ist das SVI oft das Default Gateway der Clients. Wenn das VLAN-Interface down ist, obwohl die Konfiguration korrekt aussieht, fehlt häufig ein aktiver Port im VLAN oder das VLAN selbst ist nicht korrekt im Switching aktiv.

• Ist die IP-Adresse korrekt gesetzt?
• Ist das SVI tatsächlich up/up?
• Existieren aktive Layer-2-Ports im zugehörigen VLAN?

ARP-Tabelle zur Nachbarschaftsanalyse

show arp
show ip arp
show ip arp 192.168.10.20

Die ARP-Tabelle verbindet IP-Adressen mit MAC-Adressen. Sie ist ein zentrales Werkzeug, wenn Hosts im selben Netz scheinbar nicht erreichbar sind.

• Fehlt ein ARP-Eintrag, wurde möglicherweise keine Kommunikation aufgebaut oder ARP-Requests bleiben unbeantwortet.
• Ein falscher oder wechselnder ARP-Eintrag kann auf IP-Konflikte oder Fehlkonfigurationen hindeuten.
• Bei Gateway-Problemen zeigt ein fehlender ARP-Eintrag häufig, dass Layer 2 nicht sauber funktioniert.

Routing-Tabelle und Pfadauswahl analysieren

show ip route
show ip route 10.10.10.0
show ip protocols

show ip route gehört zu den wichtigsten Cisco-Befehlen überhaupt. Damit wird sichtbar, ob das Gerät ein Zielnetz kennt, über welchen Next Hop es erreichbar ist und ob die Route direkt verbunden, statisch oder dynamisch gelernt wurde.

• Fehlt die Route komplett, ist das Problem meist Routing-bezogen.
• Ist eine unerwartete Route vorhanden, kann ein falscher Routing-Eintrag oder Protokollfehler vorliegen.
• Administrative Distance und Metrik helfen bei der Bewertung konkurrierender Routen.

show ip protocols ergänzt die Sicht, indem aktive Routing-Protokolle und relevante Parameter wie Timer, Filter oder Redistributon sichtbar werden.

Erreichbarkeit mit Ping und Traceroute gezielt testen

Die bekanntesten Cisco-Befehle zur Fehlersuche sind ping und traceroute. Ihr Wert liegt nicht nur im Test selbst, sondern in der richtigen Interpretation der Ergebnisse.

Ping sinnvoll einsetzen

ping 192.168.10.1
ping 10.10.20.5
ping 8.8.8.8

Mit Ping wird geprüft, ob ein Ziel grundsätzlich auf ICMP Echo Requests antwortet. Im Cisco-Kontext ist besonders der erweiterte Ping hilfreich, weil Quellinterface oder Quell-IP festgelegt werden können.

ping
Protocol [ip]:
Target IP address: 10.10.20.5
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: vlan 10

• Ein erfolgreicher Ping vom Gerät selbst bedeutet nicht automatisch, dass ein Client ebenfalls erreicht.
• Mit Source Interface lässt sich testen, ob die Kommunikation aus dem relevanten VLAN oder Interface funktioniert.
• Fehlgeschlagene Pings können durch ACLs, Firewalls oder fehlende Rückrouten verursacht werden.

Traceroute zur Pfadanalyse

traceroute 10.10.20.5
traceroute 8.8.8.8

Traceroute zeigt, über welche Hops ein Paket sein Ziel erreicht oder an welcher Stelle der Pfad abbricht. Das ist besonders wertvoll bei Routing-Problemen zwischen Standorten oder bei asymmetrischen Routen.

• Bricht der Pfad am ersten Hop ab, liegt das Problem oft lokal am Gateway oder Routing-Ausgang.
• Ein später Abbruch spricht eher für ein Problem weiter im Pfad, etwa bei WAN, VPN oder Upstream-Router.
• Ungewöhnliche Zwischenstationen können auf falsche Routen oder Umleitungen hinweisen.

ACLs, NAT und Sicherheitsmechanismen überprüfen

Nicht jede Nichterreichbarkeit ist ein Routing-Fehler. Häufig blockieren ACLs oder NAT-Regeln den Datenverkehr. Gerade in segmentierten Netzen oder am Internet-Edge sind diese Prüfungen unverzichtbar.

Access Control Lists kontrollieren

show access-lists
show ip access-lists
show running-config | include access-group

Mit diesen Befehlen lässt sich feststellen, welche ACLs existieren, wie sie aufgebaut sind und an welchen Interfaces sie angewendet werden. Wichtig ist dabei nicht nur die Logik der Regel, sondern auch ihre Position in der Liste.

• ACLs werden von oben nach unten ausgewertet.
• Eine zu allgemein formulierte Deny-Regel blockiert oft mehr Verkehr als beabsichtigt.
• Ein fehlender Permit-Eintrag führt durch implizites Deny zum Verwerfen des Traffics.

NAT-Status prüfen

show ip nat translations
show ip nat statistics
show running-config | section ip nat

Bei Internetproblemen oder bei Verbindungen aus privaten Netzen heraus ist NAT ein häufiger Einflussfaktor. Wenn Übersetzungen fehlen oder falsch erfolgen, funktionieren Ziele außerhalb des lokalen Netzes nicht korrekt.

• Werden Sessions überhaupt in die NAT-Tabelle eingetragen?
• Ist die Inside-/Outside-Zuordnung korrekt?
• Greifen die richtigen Access-Listen oder Route-Maps für NAT?

DHCP- und Nachbardienste auf Cisco-Geräten prüfen

Viele Cisco-Geräte übernehmen selbst DHCP-Funktionen oder leiten DHCP-Anfragen weiter. Deshalb gehören auch DHCP-Befehle zu den wichtigen Werkzeugen der Netzwerk-Fehlersuche.

DHCP-Status kontrollieren

show ip dhcp pool
show ip dhcp binding
show ip dhcp server statistics
show running-config | section dhcp

Mit diesen Befehlen lässt sich prüfen, ob der Pool korrekt angelegt wurde, wie viele Leases vergeben sind und ob Anfragen erfolgreich verarbeitet wurden. In VLAN-Umgebungen sollte zusätzlich das Relay geprüft werden.

show running-config interface vlan 20

• Ist ein ip helper-address gesetzt?
• Zeigt er auf den richtigen Server?
• Erhalten Clients Parameter aus dem richtigen Pool?

DHCP Snooping und Schutz vor Fehlquellen

show ip dhcp snooping
show ip dhcp snooping binding

DHCP Snooping schützt vor unerlaubten DHCP-Servern und liefert gleichzeitig wertvolle Diagnoseinformationen. Wenn Clients falsche Gateways oder DNS-Server erhalten, kann ein Rogue DHCP Server die Ursache sein.

Routing-Protokolle detailliert untersuchen

In komplexeren Cisco-Netzen reicht der Blick in die Routing-Tabelle allein oft nicht aus. Dann müssen Nachbarschaften und Datenbanken der Routing-Protokolle untersucht werden.

OSPF, EIGRP und BGP prüfen

show ip ospf neighbor
show ip ospf database
show ip eigrp neighbors
show ip eigrp topology
show ip bgp summary
show ip bgp

• Fehlende OSPF-Nachbarn deuten oft auf Area-, Timer-, MTU- oder Authentifizierungsprobleme hin.
• Instabile EIGRP-Neighbors weisen häufig auf Layer-3-Instabilität oder AS-Fehler hin.
• Bei BGP sind Session-Status, Prefix-Anzahl und empfangene Routen besonders wichtig.

Diese Befehle sind entscheidend, wenn Zielnetze dynamisch verteilt werden und nicht klar ist, warum eine Route fehlt oder falsch priorisiert wird.

Debug-Befehle mit Vorsicht einsetzen

Debugs liefern sehr tiefe Einblicke, können aber auf produktiven Geräten CPU und Logging stark belasten. Deshalb sollten sie nur gezielt, zeitlich begrenzt und idealerweise mit vorbereiteter Filterung verwendet werden.

Typische Debug-Kommandos

debug ip icmp
debug ip packet
debug ip dhcp server events
undebug all

• debug ip icmp zeigt ICMP-bezogene Ereignisse und hilft bei Ping-Analysen.
• debug ip dhcp server events ist nützlich, wenn Clients keine Adressen erhalten.
• debug ip packet sollte äußerst vorsichtig eingesetzt werden, da es sehr viele Informationen erzeugt.

Nach jeder Debug-Session sollte das Debugging aktiv beendet werden:

undebug all

Empfohlene Reihenfolge wichtiger Cisco-Befehle im Störungsfall

Die größte Stärke der Cisco CLI entfaltet sich, wenn Befehle methodisch kombiniert werden. Eine sinnvolle Reihenfolge reduziert Suchzeit und verhindert Fehldiagnosen.

Praktischer Ablauf für die Fehlersuche

• Zuerst Status erfassen mit show ip interface brief und show interfaces.
• Danach Layer 2 prüfen mit show vlan brief, show interfaces trunk und show mac address-table.
• Im nächsten Schritt Layer 3 analysieren mit show arp und show ip route.
• Erreichbarkeit mit erweitertem ping und traceroute verifizieren.
• Bei Bedarf ACLs, NAT, DHCP oder Routing-Protokolle gezielt prüfen.
• Nur wenn die Ursache noch unklar ist, Debug-Kommandos kontrolliert einsetzen.

Befehle mit besonders hohem Praxiswert

show ip interface brief
show interfaces
show vlan brief
show interfaces trunk
show mac address-table
show arp
show ip route
show access-lists
ping
traceroute
show logging

Diese Befehle bilden in der Praxis das Kernset für viele Troubleshooting-Szenarien. Wer ihre Ausgabe sicher interpretieren kann, erkennt typische Fehlerbilder wie falsche VLAN-Zuordnung, fehlende Route, defektes Uplink-Interface, ARP-Probleme oder ACL-Blockaden deutlich schneller und belastbarer als mit rein symptomorientierter Analyse.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.