19.6 Geräteinformationen automatisch auslesen im Lab

Geräteinformationen im Lab automatisch auszulesen ist einer der sinnvollsten und praxisnächsten Einstiege in die Netzwerkautomatisierung. Gerade im CCNA- und frühen Automation-Umfeld liefert dieser Anwendungsfall einen besonders hohen Lernwert, weil mehrere wichtige Grundlagen zusammenkommen: Management-Erreichbarkeit, SSH-Zugriff, Python-Skripte, strukturierte Datenspeicherung, saubere Fehlersuche und der Übergang von manueller CLI-Arbeit hin zu reproduzierbaren Prozessen. Anders als bei schreibenden Änderungen ist das automatisierte Auslesen von Geräteinformationen meist risikoarm. Genau deshalb eignet es sich hervorragend für erste echte Automatisierungsübungen im Lab. Network Engineers lernen dabei nicht nur, wie Daten von Routern und Switches abgefragt werden, sondern auch, wie aus einzelnen Show-Befehlen ein nützlicher Inventar-, Status- oder Dokumentationsprozess entsteht.

Warum das automatische Auslesen von Geräteinformationen im Lab so wertvoll ist

Read-Only-Automatisierung ist der ideale Einstieg

Wer Netzwerkautomatisierung lernt, sollte nicht mit komplexen Massenänderungen beginnen, sondern mit lesenden Aufgaben. Das automatische Auslesen von Geräteinformationen ist dafür ideal, weil es inhaltlich sehr praxisnah und gleichzeitig technisch überschaubar ist. Es erlaubt erste Automatisierungserfolge, ohne sofort produktionsnahe Risiken zu simulieren.

• Keine Konfiguration wird verändert.
• Fehler im Skript sind leichter einzugrenzen.
• SSH, Python und Gerätezugriff werden gemeinsam geübt.
• Die Ergebnisse lassen sich sofort mit manuellen CLI-Ausgaben vergleichen.

Gerade im Lab entsteht dadurch ein kontrollierter Lernraum, in dem technische Grundlagen sauber aufgebaut werden können.

Viele spätere Automatisierungsaufgaben bauen genau darauf auf

Das Auslesen von Geräteinformationen ist nicht nur eine Anfängerübung, sondern ein echter Grundbaustein moderner Netzwerkarbeit. Spätere Prozesse wie Inventarisierung, Dokumentation, Compliance-Prüfung, Monitoring-Vorbereitung oder Backup-Validierung bauen direkt auf derselben Grundidee auf: Geräte automatisiert abfragen und Ergebnisse weiterverarbeiten.

• Welche Plattform läuft auf dem Gerät?
• Welche Softwareversion ist aktiv?
• Welche Interfaces existieren und in welchem Status sind sie?
• Welche Seriennummer oder welches Modell wird gemeldet?
• Welche Management-IP ist aktuell konfiguriert?

Wer diese Basis im Lab sicher beherrscht, legt damit ein sehr belastbares Fundament für weitere Automation-Schritte.

Welche Geräteinformationen sich besonders gut für erste Übungen eignen

System- und Inventardaten

Besonders gut eignen sich Informationen, die auf fast jedem Router oder Switch verfügbar sind und sich relativ stabil verhalten. Dadurch werden Ergebnisse im Lab gut vergleichbar und die Automatisierungslogik bleibt übersichtlich.

• Hostname
• Modell und Plattform
• Softwareversion
• Seriennummer
• Uptime

Typische CLI-Befehle dafür sind:

show version
show inventory
show running-config | include hostname

Diese Informationen haben hohen praktischen Nutzen und sind gleichzeitig leicht verständlich.

Interface- und Managementinformationen

Ein zweiter sehr sinnvoller Bereich sind Interface-Daten. Sie verbinden Automatisierung direkt mit klassischer Netzwerktechnik und helfen dabei, Statusinformationen nicht nur als Text, sondern als strukturierte Daten zu betrachten.

• Interface-Namen
• Link-Status
• IP-Adressen
• Beschreibungen
• Administrativer und operativer Zustand

Typische CLI-Befehle:

show ip interface brief
show interfaces description
show interfaces status

Gerade im Lab lassen sich diese Daten gut mit der physischen oder logischen Topologie vergleichen.

Welche Voraussetzungen im Lab erfüllt sein sollten

Ein sauberer Managementzugang zu den Geräten

Damit Geräteinformationen automatisiert ausgelesen werden können, muss der Zugriff auf die Geräte zuverlässig funktionieren. Im Lab bedeutet das in der Regel, dass alle Geräte eine klare Management-IP haben und per SSH vom Automation-Host erreichbar sind.

• Jedes Gerät benötigt eine eindeutige Management-Adresse.
• SSH muss aktiviert sein.
• Benutzername und Passwort oder Schlüssel müssen bekannt sein.
• Der Automation-Host muss IP-Konnektivität zu allen Zielsystemen haben.

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

conf t
hostname R1
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

Erst wenn diese Basis stimmt, sollte die eigentliche Automatisierung beginnen.

Erreichbarkeit vor dem Skriptstart manuell prüfen

Ein häufiger Anfängerfehler besteht darin, sofort im Python-Skript nach Fehlern zu suchen, obwohl der SSH-Zugriff oder die IP-Erreichbarkeit noch gar nicht sauber geprüft wurden. Deshalb sollte vor der ersten Automatisierung immer eine kurze manuelle Verifikation erfolgen.

Vom Automation-Host aus:

ping 192.0.2.101
ssh admin@192.0.2.101

Auf dem Gerät selbst:

show ip interface brief
show ip ssh
show running-config | section line vty

Diese Grundchecks sparen später viel Zeit bei der Fehlersuche.

Das Python-Umfeld für Lab-Abfragen vorbereiten

Mit einer kleinen und sauberen Bibliotheksbasis starten

Für erste SSH-basierte Automatisierungsaufgaben im Lab eignet sich Python sehr gut. Besonders praktisch ist eine schlanke Bibliothek wie Netmiko, weil damit Show-Befehle relativ einfach an Netzwerkgeräte gesendet werden können. Der Einstieg sollte bewusst einfach bleiben.

Ein typisches Setup könnte so aussehen:

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

Damit entsteht eine saubere Python-Umgebung, in der erste Geräteabfragen stabil getestet werden können.

Die Verzeichnisstruktur früh ordentlich halten

Auch im Lab lohnt sich eine klare Struktur. Gerade wenn mehrere Skripte, Inventardateien und Ausgaben entstehen, hilft Ordnung dabei, den Überblick zu behalten.

• scripts/ für Python-Skripte
• inventory/ für Gerätedaten
• outputs/ für gesammelte Ergebnisse
• notes/ für kurze Lab-Notizen

Diese kleine Disziplin erleichtert später auch den Einsatz von Git und die Wiederverwendung von Skripten.

Mit dem ersten Skript Geräteinformationen auslesen

Ein einzelnes Gerät und ein einzelner Befehl

Der beste Einstieg ist ein sehr kleines Skript, das genau ein Gerät verbindet und genau einen Show-Befehl ausführt. So werden Verbindung, Befehl und Ausgabe klar nachvollziehbar.

Ein einfaches 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 version")
    print(output)

Dieses Skript trainiert mehrere Grundprinzipien gleichzeitig:

• Gerätedaten werden strukturiert definiert.
• Eine SSH-Verbindung wird aufgebaut.
• Ein Show-Befehl wird automatisiert gesendet.
• Die Antwort erscheint als Text im Terminal.

Genau dieser erste Erfolg macht die Verbindung zwischen Python und klassischer Netzwerktechnik greifbar.

Die Ausgabe bewusst mit der CLI vergleichen

Nach dem ersten Skriptlauf ist es sinnvoll, dieselbe Information noch einmal manuell per SSH und CLI zu prüfen. So wird klar, dass das Skript keine „magischen“ Daten liefert, sondern bekannte Geräteinformationen automatisiert abruft.

• Stimmt die Version mit der manuellen Ausgabe überein?
• Ist die Ausgabe vollständig?
• Gibt es Zeilenumbrüche oder Formatunterschiede?

Diese Verifikation fördert das Verständnis und reduziert blinden Werkzeugglauben.

Mehrere relevante Befehle in einem Skript kombinieren

Ein kleines Geräteprofil automatisch erfassen

Im nächsten Schritt sollte nicht nur ein einziger Befehl, sondern ein kleines Bündel typischer Informationsbefehle automatisch ausgeführt werden. So entsteht ein erster einfacher Inventar- oder Statusreport.

Ein Beispiel:

from netmiko import ConnectHandler

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

commands = [
    "show version",
    "show inventory",
    "show ip interface brief"
]

with ConnectHandler(**device) as conn:
    for cmd in commands:
        print(f"=== {cmd} ===")
        print(conn.send_command(cmd))

Dieses Skript ist bereits deutlich praxisnäher, weil es mehrere Sichtweisen auf dasselbe Gerät kombiniert.

• Systemdaten
• Inventardaten
• Interface-Übersicht

Genau daraus entstehen später oft kleine Dokumentations- oder Auditskripte.

Mit sinnvollen Überschriften arbeiten

Gerade wenn mehrere Befehle gesammelt werden, ist es hilfreich, die Ausgaben sichtbar zu strukturieren. Das macht die Resultate besser lesbar und bereitet auf spätere Speicherung in Dateien vor.

• Welcher Block gehört zu welchem Befehl?
• Wo beginnt die Interface-Übersicht?
• Wo stehen Modell- und Versionsinformationen?

Auch kleine Formatierungsentscheidungen sind im Lab nützlich, weil sie zeigen, wie aus Rohoutput später brauchbare Informationen werden.

Mehrere Geräte automatisiert abfragen

Mit einer kleinen Geräteliste arbeiten

Sobald die Abfrage eines einzelnen Geräts stabil funktioniert, sollte der nächste Schritt eine kleine Liste von zwei oder drei Geräten sein. Das trainiert Schleifen, Wiederholbarkeit und die Idee, dieselbe Logik auf mehrere Systeme anzuwenden.

Ein einfaches Beispiel:

from netmiko import ConnectHandler

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

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

Diese Übung ist im Lab besonders wertvoll, weil sie den Übergang von Einzeltests zu echter Automatisierungslogik markiert.

Ein kleines Inventar statt hartkodierter Daten verwenden

Noch besser ist es, Gerätedaten nicht dauerhaft im Skript selbst zu speichern, sondern in einer kleinen Inventardatei abzulegen. So wird von Anfang an sauber zwischen Daten und Logik getrennt.

Ein YAML-Beispiel:

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

Das ist nicht nur sauberer, sondern auch näher an realer Network Automation.

Ausgaben speichern und weiterverarbeiten

Geräteinformationen in Dateien sichern

Ein wichtiger nächster Schritt im Lab ist, Geräteinformationen nicht nur im Terminal auszugeben, sondern sauber in Dateien zu speichern. So wird aus einer einfachen Abfrage ein praktischer Mini-Prozess für Backup, Inventar oder Dokumentation.

Ein einfaches 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 running-config")

with open("outputs/R1_running_config.txt", "w") as f:
    f.write(output)

Diese Übung zeigt sehr praxisnah, wie aus einer Geräteabfrage ein gespeichertes Artefakt entsteht.

Gezielte Informationen statt nur ganze Textblöcke sammeln

Im nächsten Schritt sollte geübt werden, nicht nur rohe CLI-Ausgaben zu sichern, sondern gezielt bestimmte Informationen herauszufiltern oder in klareren Strukturen darzustellen.

• Nur die Hostname-Zeile erfassen
• Nur Interface-Zustände sammeln
• Nur Seriennummern extrahieren
• Nur NTP- oder Syslog-Konfiguration prüfen

So entwickelt sich die Lab-Arbeit von reiner Datensammlung hin zu echter Informationsgewinnung.

Typische Lab-Anwendungsfälle für Geräteabfragen

Ein kleines Geräteinventar automatisch erzeugen

Eine der besten Übungen im Lab ist ein Skript, das mehrere Geräte verbindet und aus jedem System grundlegende Stammdaten abruft. Ziel ist eine kleine Übersicht, die Modell, Version, Hostname und Management-IP zusammenführt.

• Welche Geräte existieren im Lab?
• Welche Softwarestände laufen?
• Welche Plattformen werden verwendet?
• Wie lauten die Hostnamen?

Diese Übung ist fachlich direkt wertvoll und trainiert gleichzeitig mehrere Automatisierungsgrundlagen.

Interface-Status und Topologiehinweise sammeln

Ein weiterer sinnvoller Anwendungsfall ist das Sammeln von Interface-Daten. Gerade im Lab hilft das, Gerätezustände mit der Topologie zu verbinden.

• Welche Interfaces sind up oder down?
• Welche IP-Adressen sind aktiv?
• Welche Ports sind administrativ deaktiviert?
• Welche Verbindungen wirken plausibel?

Typische Befehle dafür:

show ip interface brief
show interfaces description
show cdp neighbors detail
show lldp neighbors detail

So entsteht schon ein erster kleiner automationsgestützter Blick auf die Struktur des Lab-Netzes.

Fehlersuche beim automatischen Auslesen bewusst mitlernen

Typische Fehler systematisch einordnen

Gerade im Lab treten beim automatischen Auslesen häufig Fehler auf. Genau darin liegt ein wichtiger Teil des Lernwerts. Statt nur nach funktionierenden Beispielen zu suchen, sollte bewusst gelernt werden, wie solche Probleme systematisch eingeordnet werden.

• Das Gerät ist nicht erreichbar.
• SSH ist nicht aktiv.
• Benutzername oder Passwort sind falsch.
• Der device_type passt nicht zur Plattform.
• Der CLI-Befehl ist auf dem Gerät ungültig.
• Das Skript läuft, die Ausgabe ist aber fachlich nicht plausibel.

Diese Fehlerklasse sollte nicht hektisch, sondern strukturiert untersucht werden.

Verbindung, Zugriff und Ausgabe getrennt prüfen

Eine sehr hilfreiche Denkweise im Lab ist, Fehler nicht sofort als „Python-Problem“ zu betrachten. Oft liegt die Ursache auf einer anderen Ebene.

• Verbindungsebene: Ist die IP erreichbar?
• Zugriffsebene: Funktioniert SSH manuell?
• Befehlsebene: Ist der Befehl gültig?
• Logikebene: Wird die richtige Ausgabe interpretiert?

Diese Trennung ist eine zentrale Grundlage für spätere produktionsnahe Fehlersuche.

Strukturierte Arbeitsweise früh trainieren

Geräteabfragen mit Git versionieren

Schon im Lab lohnt es sich, Skripte, Inventardateien und kleine Anpassungen zu versionieren. Gerade beim Lernen entstehen viele kleine Veränderungen, und Git macht diese nachvollziehbar.

Ein einfacher Start:

git init
git add .
git commit -m "Erstes Inventar-Skript fuer Geraeteinformationen im Lab"

So werden Änderungen am Code oder an den Gerätedaten später leichter verständlich.

Nicht sofort auf perfekte Datenverarbeitung zielen

Am Anfang reicht es oft völlig aus, Daten zuverlässig zu sammeln und sauber zu speichern. Nicht jedes Lab-Skript muss sofort strukturierte Parser, JSON-Ausgabe oder komplexe Berichte erzeugen. Wichtig ist zuerst, dass der Ablauf stabil und verständlich ist.

• Verbindung sicher aufbauen
• Befehle korrekt senden
• Ausgabe nachvollziehbar speichern
• Fehler sauber erkennen

Erst danach sollte die Ausgabe schrittweise stärker strukturiert oder ausgewertet werden.

Best Practices für das automatische Auslesen von Geräteinformationen im Lab

• Mit Read-Only-Aufgaben beginnen und schreibende Automation zunächst vermeiden.
• Vor jedem Skriptlauf Erreichbarkeit und SSH-Zugriff manuell prüfen.
• Mit einem Gerät und einem einzelnen Befehl starten, bevor mehrere Geräte abgefragt werden.
• Typische, stabile Befehle wie show version, show inventory und show ip interface brief für erste Übungen nutzen.
• Gerätedaten möglichst früh von der Skriptlogik trennen und in kleinen Inventaren ablegen.
• Ausgaben nicht nur im Terminal anzeigen, sondern gezielt in Dateien speichern.
• Fehler nach Verbindung, Zugriff, Befehl und Auswertelogik getrennt einordnen.
• Lab-Skripte mit Git versionieren, um Änderungen nachvollziehbar zu halten.
• Die Ergebnisse immer wieder mit manueller CLI-Ausgabe vergleichen, um Werkzeugvertrauen mit technischem Verständnis zu verbinden.
• Von einfachen Textausgaben schrittweise zu strukturierter Datenverarbeitung übergehen.

Geräteinformationen automatisch im Lab auszulesen ist damit weit mehr als eine kleine Anfängerübung. Es ist der praktische Einstieg in eine Arbeitsweise, die klassische Netzwerktechnik mit moderner Automatisierung verbindet. Wer im Lab lernt, Router und Switches zuverlässig abzufragen, sinnvolle Informationen zu sammeln, Ergebnisse sauber zu speichern und Fehler systematisch zu analysieren, entwickelt genau die Fähigkeiten, die später für Inventarisierung, Monitoring, Dokumentation und viele weitere Automatisierungsaufgaben im Netzwerkalltag entscheidend sind.

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.