Site icon bintorosoft.com

13.2 Informationen aus Netzwerkgeräten automatisch auslesen

bintorosoft@gmail.com

Das automatische Auslesen von Informationen aus Netzwerkgeräten gehört zu den wichtigsten und zugleich sinnvollsten Einstiegsszenarien in der Netzwerkautomatisierung. Bevor Konfigurationen geändert, Standards ausgerollt oder komplexe Workflows gebaut werden, muss ein Team zunächst zuverlässig erfassen können, wie Geräte aktuell aussehen und welchen Zustand sie tatsächlich haben. Genau hier setzt die automatisierte Datenerfassung an. Sie hilft dabei, Inventardaten zu sammeln, Konfigurationsstände zu prüfen, Betriebszustände auszuwerten, Compliance-Vorgaben zu kontrollieren und Vorher-Nachher-Vergleiche bei Changes zu ermöglichen. Für Network Engineers ist das besonders wertvoll, weil sich aus manuellen Einzelabfragen mit show-Befehlen schnell ein skalierbarer, wiederholbarer und auswertbarer Prozess entwickeln lässt.

Warum das automatische Auslesen von Gerätedaten so wichtig ist

Read-Only-Automatisierung ist der ideale Einstieg

Im Netzwerkbetrieb ist das automatische Auslesen von Informationen meist der erste sinnvolle Schritt in Richtung Automatisierung. Der Grund ist einfach: Read-Only-Aufgaben sind technisch weniger riskant als produktive Konfigurationsänderungen, liefern aber sofort praktischen Nutzen. Statt sich direkt mit Write-Operationen, Rollback oder Change-Freigaben zu beschäftigen, kann ein Team zunächst lernen, wie Geräte automatisiert angesprochen, Daten gesammelt und Ergebnisse strukturiert verarbeitet werden.

Gerade in klassischen Netzwerken ist dieser Weg häufig erfolgreicher als der sofortige Einstieg mit automatischen Konfigurationsänderungen.

Netzwerkdaten sind die Basis für fast alle weiteren Automatisierungsaufgaben

Ohne verlässliche Gerätedaten bleibt jede weitergehende Automatisierung unscharf. Wer NTP-Server standardisieren, VLANs prüfen oder Routing-Änderungen validieren will, muss zunächst wissen, welche Geräte existieren, welche Softwareversionen sie nutzen, welche Interfaces aktiv sind und welcher Ist-Zustand aktuell vorliegt.

Das automatische Auslesen ist damit nicht nur ein Hilfsprozess, sondern die Datengrundlage für einen modernen, kontrollierten Netzwerkbetrieb.

Welche Informationen typischerweise ausgelesen werden

Gerätefakten und Basisinformationen

Zu den häufigsten und wichtigsten Daten gehören allgemeine Geräteinformationen. Sie werden für Inventarisierung, Dokumentation, Asset-Management und erste Automatisierungsschritte benötigt.

Typische CLI-Befehle sind zum Beispiel:

show version
show inventory
show running-config | include hostname
show ip interface brief

Diese Informationen wirken banal, sind aber in der Praxis oft der erste Baustein für eine verlässliche Source of Truth oder für ein sauber gepflegtes Inventar.

Interface- und Verbindungsdaten

Interfaces gehören zu den wichtigsten Objekten im Netzwerk. Deshalb ist das automatisierte Auslesen von Portinformationen eines der häufigsten Einsatzfelder. Hier geht es nicht nur um den Namen eines Ports, sondern auch um dessen Rolle, Zustand und Konfigurationsumgebung.

Typische CLI-Quellen:

show ip interface brief
show interfaces
show interfaces status
show interfaces counters errors
show cdp neighbors
show lldp neighbors

Gerade in Campus- und Rechenzentrumsumgebungen liefern diese Daten sofort wertvolle Erkenntnisse für Betrieb und Dokumentation.

Routing-, VLAN- und Protokollinformationen

Auch logische Daten aus Layer 2 und Layer 3 werden oft automatisiert gesammelt. Das betrifft etwa aktive Routen, OSPF-Nachbarn, BGP-Sessions, VLAN-Definitionen oder Spanning-Tree-Zustände.

Typische Befehle:

show ip route
show ip ospf neighbor
show bgp summary
show vlan brief
show spanning-tree
show mac address-table

Solche Informationen sind besonders nützlich für Troubleshooting, Validierung und Netzwerk-Reports.

Konfigurationsbezogene Informationen

Neben Betriebszuständen werden häufig auch konkrete Konfigurationsausschnitte gelesen. Das ist wichtig für Baseline-Checks, Compliance und Drift-Erkennung.

Typische CLI-Abfragen:

show running-config | include ntp
show running-config | include logging
show running-config | section aaa
show running-config | section line vty
show running-config interface GigabitEthernet0/1

Damit lassen sich Standards sehr gezielt prüfen, ohne sofort komplette Running-Configs vergleichen zu müssen.

Welche Wege es zum automatischen Auslesen gibt

CLI-basierte Datenerfassung über SSH

Der klassische und in vielen Umgebungen praktikabelste Weg besteht darin, Geräte per SSH zu verbinden und dort definierte Show-Befehle auszuführen. Dieser Ansatz ist besonders in traditionellen Enterprise-Netzen verbreitet, weil SSH fast überall verfügbar ist und die nötigen Kommandos bereits bekannt sind.

Die Kehrseite: CLI-Ausgaben sind primär für Menschen optimiert und oft nicht direkt strukturiert. Deshalb ist häufig Parsing nötig.

Strukturierte APIs und modellgetriebete Schnittstellen

Wo Geräte moderne Schnittstellen wie REST APIs, NETCONF oder RESTCONF bereitstellen, können Informationen oft strukturierter ausgelesen werden. Das reduziert Parsing-Aufwand und erleichtert die maschinelle Weiterverarbeitung.

Typische Aktivierung auf Cisco-Plattformen kann so aussehen:

conf t
netconf-yang
ip http secure-server
restconf
end

Für viele Teams bleibt SSH dennoch der erste praktische Einstieg, während APIs schrittweise ergänzt werden.

Python als Standardwerkzeug für das Auslesen von Netzwerkgeräten

Warum Python besonders gut geeignet ist

Python hat sich im Netzwerkbereich als Standard für solche Aufgaben etabliert. Die Sprache ist gut lesbar, flexibel und bietet passende Bibliotheken für SSH, APIs, Parsing und Datenverarbeitung.

Gerade beim automatischen Auslesen von Gerätedaten spielen typische Bibliotheken wie Netmiko, NAPALM, Requests, TextFSM oder xml/json-Module eine wichtige Rolle.

Einfacher SSH-Zugriff mit Netmiko

Netmiko ist für viele Network Engineers der naheliegende Startpunkt. Es vereinfacht den SSH-Zugriff auf Netzwerkgeräte und erlaubt es, Show-Befehle mit wenig Code auszuführen.

Ein einfaches Beispiel:

from netmiko import ConnectHandler

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

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

Dieses Skript verbindet sich mit einem Gerät und liest einen typischen Statusbefehl aus. Für erste Automatisierungsprojekte ist das oft völlig ausreichend.

Mehrere Geräte in einer Schleife auslesen

Der nächste Schritt besteht meist darin, dieselbe Logik auf mehrere Geräte anzuwenden. Das ist der Punkt, an dem Automatisierung im Alltag echten Zeitgewinn bringt.

Beispiel:

from netmiko import ConnectHandler

devices = [
    {
        "device_type": "cisco_ios",
        "host": "192.0.2.10",
        "username": "admin",
        "password": "password"
    },
    {
        "device_type": "cisco_ios",
        "host": "192.0.2.11",
        "username": "admin",
        "password": "password"
    }
]

for device in devices:
    with ConnectHandler(**device) as conn:
        output = conn.send_command("show version")
        print(f"=== {device['host']} ===")
        print(output)

Damit lassen sich Inventar- oder Statusdaten auf mehrere Geräte gleichzeitig anwenden.

Strukturierte Daten statt reiner CLI-Text

Warum Parsing oft notwendig wird

Ein Show-Befehl liefert zunächst Text. Für Menschen ist dieser oft gut lesbar, für Automatisierungsprozesse jedoch nur begrenzt direkt nutzbar. Sobald Ergebnisse verglichen, gespeichert, gefiltert oder in Reports überführt werden sollen, ist eine strukturierte Darstellung deutlich besser.

Beispielsweise liefert show ip interface brief wertvolle Informationen, aber ein Skript muss aus dem Text erst Hostnamen, Interfaces, IP-Adressen und Statuswerte sauber herauslösen.

TextFSM und ähnliche Werkzeuge

Für das Strukturieren von CLI-Ausgaben eignen sich Werkzeuge wie TextFSM. Damit können bestimmte Show-Befehle anhand von Templates geparst und in tabellenartige Datenstrukturen überführt werden.

Typische Quellen für Parsing:

show ip interface brief
show version
show vlan brief
show cdp neighbors

TextFSM ist besonders nützlich in Umgebungen, in denen APIs noch nicht verfügbar oder nicht flächendeckend nutzbar sind. Es ist eine praktische Brücke zwischen klassischer CLI und strukturierter Datennutzung.

NAPALM für strukturierte Read-Only-Daten

Wenn statt rohem CLI-Text lieber strukturierte Informationen ausgelesen werden sollen, ist NAPALM ein sehr interessantes Werkzeug. Es bietet für viele Plattformen einheitliche Methoden, um Gerätestände strukturiert abzurufen.

Ein Beispiel:

from napalm import get_network_driver

driver = get_network_driver("ios")
device = driver("192.0.2.10", "admin", "password")
device.open()

facts = device.get_facts()
print(facts)

device.close()

Solche Methoden liefern bereits geordnete Datenobjekte zurück, was Inventarisierung, Compliance und Reportings stark vereinfacht.

Typische Anwendungsfälle für automatisch ausgelesene Gerätedaten

Inventarisierung und Dokumentation

Ein sehr häufiger Einsatzbereich ist der Aufbau oder die Pflege eines Geräteinventars. Statt Informationen manuell aus Excel, Wikis und Einzelabfragen zusammenzutragen, können sie regelmäßig automatisiert gesammelt werden.

Das verbessert Datenqualität und Aktualität deutlich.

Pre-Checks und Post-Checks vor Changes

Vor produktiven Änderungen ist es oft wichtig, den Ausgangszustand dokumentiert zu erfassen. Nach dem Change wird derselbe Datensatz erneut gelesen und verglichen. So lassen sich Auswirkungen gezielt validieren.

Das automatische Auslesen ist damit direkt Teil eines sicheren Change-Prozesses.

Compliance- und Drift-Erkennung

Auch für Compliance ist das automatische Auslesen zentral. Ein Skript oder Tool liest Soll-relevante Informationen aus und vergleicht sie mit definierten Standards.

Gerade in größeren Netzen sind solche Prüfungen ohne automatisierte Datenerfassung kaum wirtschaftlich durchführbar.

Troubleshooting und Betriebsreports

Auch für operative Auswertungen und Reports sind automatisierte Abfragen sehr nützlich. Statt jeden Switch manuell aufzurufen, können relevante Statusdaten gesammelt und konsolidiert dargestellt werden.

Wie Ergebnisse sinnvoll gespeichert und verarbeitet werden

Nicht nur anzeigen, sondern strukturiert ablegen

Ein häufiger Anfängerfehler besteht darin, Ausgaben nur auf der Konsole anzuzeigen. Für produktive Automatisierung ist es aber oft sinnvoller, Ergebnisse in einer weiterverarbeitbaren Form zu speichern. Geeignet sind unter anderem:

Ein einfaches JSON-Beispiel:

import json

data = {
    "hostname": "fra-access-sw01",
    "version": "17.09.03",
    "mgmt_ip": "192.0.2.10"
}

with open("device_facts.json", "w") as f:
    json.dump(data, f, indent=2)

Dadurch werden Ergebnisse nicht nur angezeigt, sondern auch dauerhaft nutzbar gemacht.

Rohe und strukturierte Daten getrennt behandeln

In vielen realen Prozessen ist es sinnvoll, sowohl den Rohoutput als auch strukturierte Ergebnisse zu speichern. Der Rohoutput hilft bei Nachvollziehbarkeit und Fehlersuche, die strukturierten Daten dienen für Reports, Vergleiche und Automatisierungslogik.

Typische Fehler beim automatischen Auslesen vermeiden

Nur Einzelgeräte denken

Ein Skript, das nur für ein Gerät funktioniert, ist ein guter erster Test, aber noch kein belastbarer Betriebsprozess. Spätestens nach dem ersten Erfolg sollte sauber überlegt werden, wie mehrere Geräte, Fehlerfälle und strukturierte Ergebnisse behandelt werden.

Fehlerbehandlung weglassen

Geräte sind nicht immer erreichbar, Logins schlagen fehl, Prompts verhalten sich anders oder Befehle liefern unerwartete Rückgaben. Ohne Fehlerbehandlung werden automatische Ausleseprozesse schnell unzuverlässig.

Ein robuster Ansatz mit Netmiko sollte Ausnahmen behandeln:

from netmiko import ConnectHandler
from netmiko.exceptions import NetMikoTimeoutException, NetMikoAuthenticationException

try:
    with ConnectHandler(**device) as conn:
        print(conn.send_command("show version"))
except NetMikoAuthenticationException:
    print("Authentifizierung fehlgeschlagen.")
except NetMikoTimeoutException:
    print("Host nicht erreichbar oder Timeout.")

Alles nur als Freitext speichern

Wer Ergebnisse ausschließlich als unstrukturierten Text sichert, verschenkt viel Potenzial. Strukturierte Formate machen spätere Vergleiche, Filter und Auswertungen wesentlich einfacher.

Zugangsdaten unsicher behandeln

Gerade bei Skripten zum Auslesen wird oft leichtfertig mit Passwörtern umgegangen. Auch Read-Only-Zugänge sind sicherheitsrelevant und sollten nicht im Klartext in Skripten oder Repositories stehen.

Best Practices für das automatische Auslesen von Netzwerkgeräten

Damit wird das automatische Auslesen von Informationen aus Netzwerkgeräten zu weit mehr als nur einer technischen Spielerei. Es ist der zentrale Einstieg in belastbare Netzwerkautomatisierung, weil es Sichtbarkeit, Struktur und Wiederholbarkeit in den Betrieb bringt. Genau diese Eigenschaften sind notwendig, damit spätere Änderungen, Validierungen und Standards nicht auf Vermutungen, sondern auf verlässlichen Gerätedaten aufbauen.

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:

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

Exit mobile version