19.9 Mini-Projekt: Interface-Status automatisch prüfen

Ein Mini-Projekt zur automatischen Prüfung des Interface-Status ist ein idealer Einstieg in die praktische Netzwerkautomatisierung, weil es ein echtes Betriebsproblem mit überschaubarem technischem Aufwand verbindet. In fast jedem Netzwerkalltag müssen Engineers regelmäßig prüfen, welche Interfaces aktiv sind, welche Ports administrativ abgeschaltet wurden, wo Links unerwartet down sind und ob sich Statusänderungen zwischen Geräten oder Standorten häufen. Genau diese Aufgabe eignet sich hervorragend für ein kleines Automatisierungsprojekt im Lab. Sie ist fachlich relevant, technisch gut beherrschbar und lässt sich schrittweise erweitern. Gleichzeitig werden dabei viele Grundlagen trainiert, die für spätere Automatisierungsaufgaben entscheidend sind: Gerätezugriff per SSH, Python-Skripte, strukturierte Datensammlung, einfache Auswertung, Fehlerbehandlung und die saubere Trennung zwischen Rohdaten und interpretierter Information. Für CCNA- und frühe Automation-Lernumgebungen ist dieses Mini-Projekt deshalb besonders wertvoll, weil es klassische Netzwerktechnik und moderne Automatisierungslogik direkt zusammenführt.

Warum der Interface-Status ein gutes Automatisierungsprojekt ist

Interfaces gehören zu den wichtigsten Betriebsindikatoren

Interfaces sind im Netzwerkbetrieb eine der sichtbarsten und wichtigsten Informationsquellen. Fast jede Fehleranalyse beginnt irgendwann mit der Frage, ob ein Link physisch aktiv ist, ob ein Port administrativ deaktiviert wurde oder ob eine Schnittstelle unerwartet down gegangen ist. Genau deshalb bietet sich der Interface-Status als Automatisierungsziel besonders an.

• Ein Interface kann administrativ up, aber operativ down sein.
• Ein Port kann unerwartet deaktiviert sein.
• Uplinks und Access-Ports verhalten sich unterschiedlich.
• Management- und Datenpfade lassen sich über Interfaces nachvollziehen.

Wer diesen Bereich automatisiert prüft, arbeitet also an einer sehr realitätsnahen Aufgabe mit hoher betrieblicher Relevanz.

Das Projekt ist klein genug für ein Lab, aber fachlich nützlich

Ein gutes Mini-Projekt sollte nicht zu groß sein, aber trotzdem einen echten Nutzen zeigen. Die automatische Prüfung des Interface-Status erfüllt genau diese Anforderung. Schon mit wenigen Geräten und einfachen Show-Befehlen lässt sich ein sinnvoller Prüfprozess aufbauen.

• Keine Konfigurationsänderung notwendig
• Read-Only-Zugriff reicht aus
• Ergebnisse sind leicht mit der manuellen CLI zu vergleichen
• Ausbau in Richtung Reporting oder Alarmierung ist später möglich

Damit eignet sich das Thema ideal für eine erste oder frühe Automatisierungsübung.

Was das Mini-Projekt konkret leisten soll

Ein klares und realistisches Ziel definieren

Damit das Projekt überschaubar bleibt, sollte der Umfang bewusst klar definiert werden. Ziel ist nicht, sofort ein vollständiges Monitoring-System zu bauen, sondern einen stabilen und nachvollziehbaren Prüfprozess im Lab umzusetzen.

• Mehrere Geräte aus einem kleinen Inventar einlesen
• Per SSH auf jedes Gerät verbinden
• Den Interface-Status automatisiert abfragen
• Die Ausgabe pro Gerät auswerten oder speichern
• Auffällige Interfaces sichtbar machen
• Einfache Fehlerbehandlung für nicht erreichbare Geräte einbauen

Diese Zieldefinition ist praxisnah, aber bewusst begrenzt. Genau das macht das Projekt didaktisch sinnvoll.

Welche Fragen das Skript beantworten soll

Ein hilfreicher Weg, das Projekt zu strukturieren, ist die Frage nach dem konkreten Nutzen der Ausgabe. Was soll das Skript am Ende über die Interfaces aussagen?

• Welche Interfaces sind up?
• Welche Interfaces sind down?
• Welche Interfaces sind administrativ deaktiviert?
• Welche Geräte haben unerwartet viele inaktive Ports?
• Welche Uplinks wirken problematisch?

Diese Fragen helfen dabei, aus einer rohen CLI-Abfrage ein kleines fachliches Prüfwerkzeug zu machen.

Die Lab-Umgebung sinnvoll vorbereiten

Managementzugang zu allen Geräten sicherstellen

Wie bei fast jeder Automatisierungsaufgabe im Lab gilt auch hier: Ohne stabilen Managementzugang ist die restliche Logik wenig wert. Bevor das eigentliche Skript geschrieben wird, müssen die Geräte per SSH erreichbar sein.

Eine typische Grundkonfiguration auf Cisco-Geräten kann so aussehen:

conf t
hostname SW1
ip domain-name lab.local
username admin privilege 15 secret MeinPasswort123
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 login local
 transport input ssh
end
write memory

Diese Basis stellt sicher, dass der Automation-Host per SSH auf das Gerät zugreifen kann.

Erreichbarkeit und Interface-Ausgabe manuell prüfen

Bevor Python eingesetzt wird, sollte der Engineer die relevante CLI-Ausgabe einmal manuell prüfen. Das ist didaktisch wichtig, weil so klar wird, was das Skript später tatsächlich verarbeitet.

Typische Tests:

ping 192.0.2.101
ssh admin@192.0.2.101
show ip interface brief
show interfaces description

Gerade im Lab sollte man nicht blind automatisieren, sondern den zugrunde liegenden Datenstrom bewusst kennen.

Welcher Show-Befehl sich für das Projekt eignet

show ip interface brief als idealer Einstieg

Für ein erstes Mini-Projekt ist show ip interface brief einer der besten Befehle. Er liefert eine kompakte Übersicht, ist auf vielen Cisco-Umgebungen verfügbar und verbindet Interface-Name, IP-Adresse, administrativen Status und operativen Status in einer gut lesbaren Form.

Ein typischer Ausschnitt sieht etwa so aus:

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     192.0.2.101     YES manual up                    up
GigabitEthernet0/1     unassigned      YES unset  administratively down down
Loopback0              10.10.10.1      YES manual up                    up

Diese Ausgabe ist didaktisch ideal, weil sie mehrere Interpretationen erlaubt und sich gut für erste Parsing- oder Filterübungen eignet.

Später erweiterbar um weitere Befehle

Wenn das Grundprojekt stabil läuft, kann es später durch zusätzliche Befehle ergänzt werden. Für den Start sollte der Fokus aber auf einer einfachen und stabilen Datenquelle liegen.

• show interfaces description für Beschreibungen
• show interfaces status auf geeigneten Plattformen
• show interfaces counters errors für spätere Qualitätsprüfungen

Die erste Version des Projekts sollte jedoch bewusst kompakt bleiben.

Das Python-Umfeld für das Projekt vorbereiten

Mit einer schlanken Bibliothek arbeiten

Für SSH-basierte Abfragen im Lab eignet sich Netmiko sehr gut, weil der Aufbau übersichtlich bleibt und sich Show-Befehle relativ einfach absetzen lassen. Der technische Fokus bleibt dadurch auf dem Netzwerk und nicht auf unnötiger Komplexität im Code.

Ein einfaches Setup könnte so aussehen:

python3 -m venv venv
source venv/bin/activate
pip install netmiko

Damit entsteht eine saubere Arbeitsumgebung für das Projekt.

Eine ordentliche Projektstruktur anlegen

Auch dieses Mini-Projekt profitiert von einer kleinen, klaren Verzeichnisstruktur. So bleibt das Projekt nachvollziehbar und lässt sich später leichter erweitern.

• scripts/ für Python-Skripte
• inventory/ für Gerätedaten
• outputs/ für Berichte oder gespeicherte Ergebnisse
• logs/ für Fehlermeldungen oder Laufprotokolle

Diese Ordnung ist gerade im Lernkontext sehr wertvoll.

Mit dem ersten Ein-Geräte-Skript beginnen

Zuerst nur ein Gerät und ein Befehl

Wie bei guten Lab-Projekten üblich, sollte der erste Schritt bewusst klein sein. Ziel ist, einen einzelnen Router oder Switch per SSH zu verbinden und genau einen Show-Befehl abzusetzen.

Ein einfaches Python-Beispiel:

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.101",
    "username": "admin",
    "password": "MeinPasswort123"
}

with ConnectHandler(**device) as conn:
    output = conn.send_command("show ip interface brief")
    print(output)

Dieses Skript trainiert bereits den Kern des gesamten Projekts:

• Verbindung aufbauen
• CLI-Befehl senden
• Antwort empfangen
• Ergebnis anzeigen

Erst wenn dieser Basisschritt stabil funktioniert, sollte das Projekt erweitert werden.

Die Ausgabe mit der manuellen CLI vergleichen

Nach dem ersten erfolgreichen Skriptlauf ist es sinnvoll, die Ausgabe noch einmal manuell auf dem Gerät zu prüfen. Dadurch wird deutlich, dass das Skript keine andere Realität erzeugt, sondern bekannte Geräteinformationen automatisiert sammelt.

• Stimmt die Reihenfolge der Interfaces?
• Sind Status und Protokollwerte korrekt übernommen?
• Fehlen Zeilen oder wirken Werte unplausibel?

Diese Verifikation stärkt das Verständnis und verhindert blindes Vertrauen in die Automatisierung.

Mehrere Geräte automatisiert abfragen

Mit einer kleinen Geräteliste arbeiten

Wenn der Zugriff auf ein einzelnes Gerät funktioniert, ist der nächste logische Schritt eine Schleife über mehrere Systeme. Genau hier wird aus einer Einzelübung ein echter kleiner Automatisierungsprozess.

Ein einfaches Beispiel:

from netmiko import ConnectHandler

devices = [
    {
        "hostname": "R1",
        "device_type": "cisco_ios",
        "host": "192.0.2.101",
        "username": "admin",
        "password": "MeinPasswort123"
    },
    {
        "hostname": "SW1",
        "device_type": "cisco_ios",
        "host": "192.0.2.102",
        "username": "admin",
        "password": "MeinPasswort123"
    }
]

for device in devices:
    print(f"Verbinde zu {device['hostname']}")
    with ConnectHandler(**device) as conn:
        output = conn.send_command("show ip interface brief")
        print(output)

Damit wird die gleiche Prüflogik auf mehrere Geräte angewendet. Genau das ist der eigentliche Kern von Netzwerkautomatisierung.

Ein kleines Inventar statt harter Gerätedaten verwenden

Für eine sauberere Struktur ist es sinnvoll, Gerätedaten in ein kleines Inventar auszulagern. Auch im Lab ist das ein sehr wertvoller Schritt, weil so Daten und Skriptlogik getrennt werden.

Ein einfaches YAML-Beispiel:

devices:
  - hostname: R1
    host: 192.0.2.101
    role: router
  - hostname: SW1
    host: 192.0.2.102
    role: switch

Diese Trennung erleichtert spätere Erweiterungen enorm.

Die Ergebnisse sinnvoll speichern und strukturieren

Nicht nur im Terminal anzeigen

Für ein echtes Mini-Projekt reicht es nicht, die Ergebnisse nur kurz im Terminal zu sehen. Sie sollten so gespeichert werden, dass sie später geprüft, verglichen oder weiterverarbeitet werden können.

Ein einfacher Ansatz ist, die Ausgabe pro Gerät in eine Datei zu schreiben:

from netmiko import ConnectHandler

device = {
    "hostname": "R1",
    "device_type": "cisco_ios",
    "host": "192.0.2.101",
    "username": "admin",
    "password": "MeinPasswort123"
}

with ConnectHandler(**device) as conn:
    output = conn.send_command("show ip interface brief")

with open(f"outputs/{device['hostname']}_interfaces.txt", "w") as f:
    f.write(output)

So entsteht ein einfaches, nachvollziehbares Ergebnis pro Gerät.

Auffällige Informationen gezielt hervorheben

Noch hilfreicher wird das Projekt, wenn nicht nur Rohdaten gespeichert, sondern auffällige Zustände sichtbar gemacht werden. Schon einfache Textfilterungen bringen hier einen großen Mehrwert.

• Interfaces mit administratively down markieren
• Unerwartet down/down stehende Uplinks hervorheben
• Nur Interfaces mit IP-Adresse anzeigen
• Loopbacks und physische Ports unterscheiden

Damit wird aus einer Datensammlung eine kleine fachliche Prüfung.

Den Status fachlich interpretieren

Administrativer und operativer Zustand sind nicht dasselbe

Ein zentrales Lernziel dieses Projekts ist nicht nur das Auslesen, sondern auch das fachliche Verstehen der Daten. Gerade Interface-Statusinformationen müssen korrekt interpretiert werden.

• up/up bedeutet in vielen Fällen normale Funktion.
• administratively down/down kann völlig erwartbar sein.
• up/down oder down/down kann je nach Interface-Typ problematisch sein.

Deshalb sollte das Projekt nicht einfach nur Statuswerte sammeln, sondern auch bewusst den Unterschied zwischen erwartetem und unerwartetem Zustand thematisieren.

Lab-Topologie mitdenken

Damit die Auswertung sinnvoll bleibt, muss der Engineer die Lab-Topologie kennen. Ein unverbundener Testport darf nicht denselben Stellenwert haben wie ein Uplink zwischen zwei aktiven Geräten.

• Welche Ports sind absichtlich ungenutzt?
• Welche Interfaces sollten immer aktiv sein?
• Welche Loopbacks oder Management-Interfaces müssen up sein?

Diese fachliche Einordnung macht aus einem technischen Skript ein nützliches kleines Prüfwerkzeug.

Das Projekt robuster machen

Einfache Fehlerbehandlung ergänzen

Ein realistisches Mini-Projekt sollte nicht beim ersten Verbindungsfehler komplett abbrechen. Gerade im Lab ist es sinnvoll, grundlegende Fehlerbehandlung bewusst zu trainieren. So wird schnell sichtbar, welche Geräte erfolgreich abgefragt wurden und wo Probleme auftraten.

Ein einfaches Beispiel:

from netmiko.exceptions import NetMikoTimeoutException, NetMikoAuthenticationException

try:
    with ConnectHandler(**device) as conn:
        output = conn.send_command("show ip interface brief")
except NetMikoAuthenticationException:
    print(f"Authentifizierung fehlgeschlagen bei {device['hostname']}")
except NetMikoTimeoutException:
    print(f"Timeout bei {device['hostname']}")

Diese Erweiterung macht das Projekt deutlich realistischer und belastbarer.

Erfolgreiche und fehlgeschlagene Abfragen sichtbar machen

Neben der technischen Fehlerbehandlung ist es hilfreich, erfolgreiche und fehlgeschlagene Prüfungen klar zu protokollieren. So wird aus einem Skript ein nachvollziehbarer Ablauf.

• Welches Gerät wurde geprüft?
• Wann war die Abfrage erfolgreich?
• Bei welchem Gerät trat ein Problem auf?
• Wurde eine Datei geschrieben oder nicht?

Gerade diese Transparenz ist im späteren Produktionsumfeld entscheidend und sollte schon im Lab geübt werden.

Das Projekt fachlich erweitern

Zusätzliche Interface-Befehle ergänzen

Wenn das Grundprojekt stabil funktioniert, kann es sinnvoll erweitert werden. Eine gute Erweiterung ist die Kombination mehrerer Interface-bezogener Befehle, um mehr Kontext zu erhalten.

• show interfaces description
• show interfaces status
• show interfaces counters errors

So lassen sich nicht nur Statuswerte sammeln, sondern auch Beschreibungen und mögliche Qualitätsprobleme berücksichtigen.

Kleine Reports erzeugen

Ein weiterer sinnvoller Ausbau besteht darin, aus den Daten kleine Berichte zu erzeugen. Das kann zunächst sehr einfach sein.

• Welche Geräte haben unerwartet viele down-Interfaces?
• Welche Interfaces mit IP-Adresse sind nicht aktiv?
• Welche Ports haben keine Beschreibung?

Damit wächst das Projekt von einer einfachen Abfrage zu einem kleinen Prüf- und Dokumentationsprozess.

Typische Fehler in diesem Mini-Projekt

Nur Rohdaten sammeln, aber nichts daraus ableiten

Ein häufiger Fehler ist, zwar korrekt Daten einzusammeln, aber keinen fachlichen Mehrwert daraus zu ziehen. Das Skript bleibt dann eine reine Transportübung. Besser ist es, bewusst einfache Interpretationen oder Hervorhebungen einzubauen.

Geräte ohne Kontext gleich behandeln

Nicht jedes down ist ein Problem. Wer alle Interfaces gleich bewertet, erzeugt schnell irreführende Ergebnisse. Deshalb sollte der Lab-Kontext immer mitgedacht werden.

Fehlersuche zu schnell im Python-Code suchen

Wenn ein Gerät nicht erreichbar ist oder SSH falsch konfiguriert wurde, hilft keine Änderung am Parsing. Die Trennung zwischen Netzwerkzugang, Login, Befehl und Logik muss bewusst geübt werden.

Ausgabe nicht regelmäßig mit der CLI vergleichen

Gerade im Lab ist es wichtig, Ergebnisse immer wieder gegen die manuelle CLI zu verifizieren. Nur so bleibt das Verständnis für den Ursprung der Daten erhalten.

Git und saubere Entwicklung im Mini-Projekt nutzen

Versionierung schon im Lab einsetzen

Auch ein kleines Interface-Status-Projekt profitiert von Git. Gerade beim Lernen verändern sich Code, Inventare und Ausgabestruktur schnell. Versionsverwaltung macht diese Entwicklung nachvollziehbar.

Ein einfacher Start:

git init
git add .
git commit -m "Initiales Mini-Projekt zur automatischen Interface-Pruefung"

So lassen sich spätere Änderungen an Logik, Filterung oder Fehlerbehandlung leichter zurückverfolgen.

In kleinen Schritten erweitern

Das Projekt sollte nicht in einem großen Sprung entstehen. Sinnvoller ist eine schrittweise Entwicklung.

• Zuerst ein Gerät und ein Befehl
• Dann mehrere Geräte
• Dann Speicherung pro Gerät
• Dann Inventar auslagern
• Dann Fehlerbehandlung ergänzen
• Dann Auswertung und kleine Reports erweitern

Diese Vorgehensweise ist technisch und didaktisch deutlich besser beherrschbar.

Best Practices für das Mini-Projekt „Interface-Status automatisch prüfen“

• Mit show ip interface brief als einfachem und stabilen Startbefehl beginnen.
• Vor jedem Skriptlauf Management-Erreichbarkeit und SSH-Zugang manuell prüfen.
• Zunächst nur ein Gerät automatisieren und erst danach mehrere Systeme einbeziehen.
• Gerätedaten früh in ein kleines Inventar auslagern.
• Ausgaben nicht nur im Terminal anzeigen, sondern pro Gerät in Dateien speichern.
• Statuswerte fachlich interpretieren und nicht jedes down automatisch als Fehler werten.
• Fehlerbehandlung für Timeout und Authentifizierungsprobleme bewusst einbauen.
• Die Ergebnisse regelmäßig mit manueller CLI-Ausgabe vergleichen.
• Das Projekt schrittweise um Beschreibungen, Fehlerzähler oder kleine Reports erweitern.
• Skripte, Inventare und Anpassungen mit Git versionieren.

Dieses Mini-Projekt zeigt sehr gut, wie aus einer scheinbar kleinen Aufgabe ein echter Einstieg in die Netzwerkautomatisierung wird. Die automatische Prüfung des Interface-Status verbindet Managementzugriff, CLI-Verständnis, Python-Logik, Datensammlung, Auswertung und Fehlersuche in einer Form, die im Lab gut kontrollierbar und zugleich fachlich nützlich ist. Wer diese Aufgabe sauber umsetzt, lernt nicht nur, Interfaces automatisiert abzufragen, sondern entwickelt ein praktisches Verständnis dafür, wie aus klassischen Netzwerkfragen kleine, robuste und ausbaufähige Automatisierungsprozesse entstehen.

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.