19.10 Mini-Projekt: Standardkonfiguration im Netzwerk verteilen

Ein Mini-Projekt zur Verteilung einer Standardkonfiguration im Netzwerk ist ein idealer nächster Schritt nach ersten Read-Only-Übungen wie Inventarisierung, Backup oder Interface-Prüfung. Genau hier beginnt der Übergang von reinem Auslesen hin zu echter, schreibender Netzwerkautomatisierung. Für angehende Network Engineers ist das ein besonders wichtiger Moment, weil sich damit das Verständnis der Automatisierung grundlegend erweitert: Ein Skript oder Playbook liest nicht mehr nur Informationen, sondern verändert aktiv den Zustand eines Geräts. Gerade deshalb eignet sich ein kleines, klar abgegrenztes Standardisierungsprojekt im Lab hervorragend als Lernfeld. Es verbindet Gerätezugriff, Inventardaten, Templates, Verifikation, Fehlerbehandlung und vorsichtiges Change-Denken in einer Aufgabe, die fachlich realistisch und technisch beherrschbar bleibt. Wer lernt, eine einfache Standardkonfiguration kontrolliert auf mehrere Geräte zu verteilen, versteht nicht nur ein einzelnes Automatisierungsskript, sondern einen Kernprozess moderner Netzwerkarbeit.

Warum ein Standardkonfigurations-Projekt didaktisch so wertvoll ist

Viele Netzwerkänderungen folgen wiederkehrenden Mustern

Ein großer Teil operativer Netzwerkarbeit besteht aus wiederkehrenden Basisänderungen. Es geht häufig nicht um einzigartige Spezialkonfigurationen, sondern um standardisierte Blöcke, die auf vielen Geräten ähnlich oder identisch vorkommen.

• NTP-Server sollen auf mehreren Geräten gesetzt werden.
• Syslog-Ziele müssen vereinheitlicht werden.
• Ein Login-Banner soll auf allen Lab-Systemen erscheinen.
• Basisparameter für Management oder SSH sollen konsistent sein.

Genau solche Aufgaben eignen sich hervorragend für ein Mini-Projekt, weil der fachliche Nutzen klar erkennbar ist und die technische Umsetzung überschaubar bleibt.

Der Schritt von Read-Only zu Write-Automation ist zentral

Viele Einsteiger arbeiten zuerst mit sicheren, lesenden Automatisierungsaufgaben. Das ist sinnvoll. Irgendwann muss aber auch geübt werden, wie Konfigurationen kontrolliert verändert werden. Ein kleines Standardprojekt im Lab ist dafür ideal, weil es genau diese Lücke schließt.

• SSH-Verbindung wird nicht nur zum Lesen, sondern zum Konfigurieren genutzt.
• Der Engineer lernt, Konfigurationsblöcke bewusst vorzubereiten.
• Verifikation vor und nach der Änderung wird notwendig.
• Fehlerbehandlung wird wichtiger als bei reinen Show-Befehlen.

Damit ist dieses Projekt ein sehr realistischer Zwischenschritt auf dem Weg zu größerer Netzwerkautomatisierung.

Ein sinnvolles Projektziel definieren

Was mit „Standardkonfiguration verteilen“ gemeint ist

Für ein gutes Mini-Projekt sollte der Umfang klar begrenzt werden. Ziel ist nicht, komplette Gerätekonfigurationen neu aufzubauen oder eine Zero-Touch-Provisioning-Lösung zu entwickeln. Viel sinnvoller ist ein kleiner, stabiler Standardblock, der auf mehrere Geräte verteilt wird.

• Ein Login-Banner setzen
• Zwei NTP-Server eintragen
• Einen oder zwei Syslog-Hosts konfigurieren
• Einen einfachen Basisparameter für Management ergänzen

Ein typischer Beispielblock könnte so aussehen:

conf t
banner motd ^Nur Lab-Zugriff erlaubt^
ntp server 10.10.10.10
ntp server 10.10.10.11
logging host 10.20.20.20
end
write memory

Dieser Umfang ist klein genug für das Lab und groß genug, um einen echten Standardisierungsprozess zu trainieren.

Bewusst einen risikoarmen Konfigurationsbereich wählen

Gerade im Lernumfeld ist es wichtig, nicht mit kritischen Routing-, Security- oder Interface-Änderungen zu beginnen. Das Ziel sollte eine Konfiguration sein, deren Wirkung klar nachvollziehbar und deren Fehlerrisiko beherrschbar ist.

• Banner sind sehr gut geeignet.
• NTP- und Syslog-Konfigurationen sind ebenfalls sinnvoll.
• Komplexe ACLs oder Routing-Policies sind für den Einstieg weniger geeignet.

Diese bewusste Auswahl ist eine wichtige Best Practice für schreibende Lab-Automatisierung.

Die Lab-Umgebung für das Projekt vorbereiten

Mehrere Geräte mit stabilem SSH-Zugang

Damit eine Standardkonfiguration verteilt werden kann, müssen die Zielgeräte sauber per SSH erreichbar sein. Diese Voraussetzung ist nicht nur technisch wichtig, sondern auch didaktisch: Ohne stabilen Managementzugang wird aus einem Konfigurationsprojekt schnell eine chaotische Fehlersuche.

Eine typische Grundkonfiguration auf Cisco-Geräten könnte 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 Grundlage bei allen Zielgeräten funktioniert, sollte die eigentliche Automatisierung beginnen.

Management-IP und manuelle Erreichbarkeit verifizieren

Vor dem ersten Skriptlauf sollten alle Geräte manuell getestet werden. Das klingt banal, ist aber einer der wichtigsten Schritte. Viele vermeintliche Python- oder Toolprobleme sind in Wirklichkeit nur unklare Managementpfade oder falsche Zugangsdaten.

Typische Prüfungen vom Automation-Host:

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 Basiskontrolle verhindert später viele unnötige Irrwege.

Geräteinventar und Projektstruktur sauber anlegen

Gerätedaten nicht im Code verstecken

Auch für ein Mini-Projekt ist es sinnvoll, die Zielgeräte nicht dauerhaft direkt im Python-Skript zu hinterlegen. Ein kleines Inventar in YAML reicht aus, um saubere Trennung zwischen Daten und Logik zu üben.

Ein einfaches Inventar könnte so aussehen:

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

Diese Struktur hat mehrere Vorteile:

• Neue Geräte können leichter ergänzt werden.
• Das Skript bleibt übersichtlicher.
• Datenprobleme und Codeprobleme lassen sich besser trennen.

Eine klare Projektstruktur verwenden

Auch im Lab lohnt sich eine kleine, logische Projektstruktur. Sie hilft dabei, das Projekt sauber zu entwickeln und später leichter zu erweitern.

• scripts/ für Python-Code
• inventory/ für Gerätedaten
• templates/ für Standardkonfigurationen
• logs/ für Laufmeldungen oder Fehler
• outputs/ für Prüf- oder Statusdateien

Gerade diese kleine Ordnung trainiert direkt eine professionellere Arbeitsweise.

Den Standardblock zuerst bewusst manuell testen

Die Konfiguration muss fachlich klar sein

Bevor eine Standardkonfiguration automatisiert verteilt wird, sollte sie fachlich eindeutig definiert und mindestens auf einem Gerät manuell getestet sein. Gute Automatisierung ersetzt nicht fachliche Klarheit. Sie setzt sie voraus.

• Welche Zeilen gehören zwingend zum Standard?
• Sind alle Zielgeräte dafür geeignet?
• Gibt es Rollen- oder Plattformunterschiede?
• Welche Zeilen sind optional, welche verpflichtend?

Gerade bei NTP- und Syslog-Standards ist es hilfreich, die Zielkonfiguration vorab bewusst zu formulieren.

Vorher-Nachher-Zustand einmal manuell prüfen

Ein sehr sinnvoller Schritt ist, die Ausgangslage an einem einzelnen Testgerät manuell zu prüfen und die Wirkung des Standardblocks bewusst zu sehen.

Typische Vorprüfungen:

show running-config | include ntp
show running-config | include logging
show running-config | include banner

Danach kann die Konfiguration manuell gesetzt und erneut geprüft werden. Erst wenn die Wirkung fachlich klar ist, sollte sie automatisiert ausgerollt werden.

Mit einem sehr kleinen Automatisierungsschritt beginnen

Zuerst nur ein Gerät automatisieren

Wie bei vielen Lab-Projekten gilt auch hier: Nicht sofort mehrere Geräte gleichzeitig verändern. Der erste Schritt sollte immer sein, die Standardkonfiguration auf genau einem Gerät per Skript anzuwenden.

Ein einfaches Python-Beispiel mit Netmiko:

from netmiko import ConnectHandler

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

commands = [
    "banner motd ^Nur Lab-Zugriff erlaubt^",
    "ntp server 10.10.10.10",
    "ntp server 10.10.10.11",
    "logging host 10.20.20.20"
]

with ConnectHandler(**device) as conn:
    output = conn.send_config_set(commands)
    print(output)

Dieses Skript ist einfach, aber vollständig genug, um den Kern des Projekts zu zeigen: verbinden, Konfigurationsmodus betreten, Standardblock anwenden und Rückmeldung auswerten.

Die Wirkung direkt am Gerät verifizieren

Nach dem ersten Lauf ist die wichtigste Frage nicht, ob das Skript ohne Exception endete, sondern ob der gewünschte Zustand wirklich auf dem Gerät sichtbar ist. Genau diese Verifikation muss früh als Gewohnheit trainiert werden.

Typische Nachprüfungen:

show running-config | include ntp
show running-config | include logging
show running-config | include banner

So wird aus einer bloßen Schreiboperation ein kontrollierter Mini-Change.

Den Standard auf mehrere Geräte ausrollen

Mit einer Schleife über das Inventar arbeiten

Wenn die Konfiguration auf einem Gerät sauber funktioniert, kann derselbe Standard auf mehrere Systeme im Lab ausgeweitet werden. Genau hier wird die eigentliche Stärke der Automatisierung sichtbar: einmal definierte Logik wird mehrfach wiederverwendet.

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"
    }
]

commands = [
    "banner motd ^Nur Lab-Zugriff erlaubt^",
    "ntp server 10.10.10.10",
    "ntp server 10.10.10.11",
    "logging host 10.20.20.20"
]

for device in devices:
    print(f"Konfiguriere {device['hostname']}")
    with ConnectHandler(**device) as conn:
        output = conn.send_config_set(commands)
        print(output)

Damit ist das eigentliche Mini-Projekt bereits funktionsfähig.

Die Grenzen einer gemeinsamen Befehlsliste verstehen

Für einen ersten Standardblock ist eine feste Befehlsliste völlig ausreichend. Gleichzeitig sollte bereits im Lab verstanden werden, dass dieser Ansatz nur solange gut funktioniert, wie alle Geräte wirklich denselben Standard erhalten sollen.

• Banner können oft identisch sein.
• NTP- oder Syslog-Werte sind oft standardisierbar.
• Hostnamen oder standortspezifische Adressen sind dagegen variabel.

Genau an dieser Stelle entsteht später der Bedarf für Templates und Variablen.

Mit Templates arbeiten, wenn der Standard variabel wird

Ein Template für den Standardblock erstellen

Sobald einzelne Werte pro Gerät oder Rolle variieren, ist ein Template sinnvoller als eine fest codierte Befehlsliste. Gerade im Lab kann dieser Übergang sehr gut trainiert werden.

Ein einfaches Jinja2-Template könnte so aussehen:

banner motd ^{{ banner_text }}^
ntp server {{ ntp_server_1 }}
ntp server {{ ntp_server_2 }}
logging host {{ syslog_server_1 }}

Die passenden Variablen kommen dann aus dem Inventar oder einer separaten Datendatei.

Die gerenderte Ausgabe zuerst nur prüfen

Bevor eine generierte Standardkonfiguration auf Geräte übertragen wird, sollte sie im Lab immer erst gerendert und visuell kontrolliert werden.

• Fehlen Variablen?
• Ist der Banner korrekt?
• Sind die NTP- und Syslog-Werte plausibel?
• Entspricht die Ausgabe wirklich dem gewünschten Standard?

Diese Gewohnheit ist für produktionsnahe Automatisierung entscheidend und sollte schon im Lab selbstverständlich werden.

Vorher-Nachher-Prüfungen in das Projekt einbauen

Pre-Checks vor der Änderung

Ein professioneller Standard-Rollout beginnt nicht erst mit dem Schreibvorgang, sondern mit bewussten Vorprüfungen. Auch im Lab lohnt es sich, diese Disziplin früh zu üben.

• Ist das Gerät erreichbar?
• Ist der aktuelle Zustand bekannt?
• Fehlen bestimmte Standardzeilen bereits oder sind sie teilweise vorhanden?

Typische Pre-Checks:

show running-config | include ntp
show running-config | include logging
show running-config | include banner

Damit wird klarer, was sich durch den Change tatsächlich verändert.

Post-Checks nach der Änderung

Nach dem Rollout sollten dieselben oder passende Folgeprüfungen stattfinden. So wird verifiziert, dass die Standardkonfiguration nicht nur gesendet, sondern wirklich übernommen wurde.

Typische Post-Checks:

show running-config | include ntp
show running-config | include logging
show running-config | include banner

Gerade im Lab ist dieser Vorher-Nachher-Vergleich didaktisch besonders wertvoll.

Fehlerbehandlung und vorsichtige Rollout-Logik einbauen

Verbindungs- und Zugriffsfehler sauber behandeln

Ein sinnvolles Mini-Projekt sollte nicht beim ersten Problem komplett abbrechen. Deshalb ist es hilfreich, einfache Fehlerbehandlung einzubauen. Das ist nicht nur technisch nützlich, sondern trainiert auch eine produktionsnähere Denkweise.

Ein einfaches Muster:

from netmiko.exceptions import NetMikoTimeoutException, NetMikoAuthenticationException

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

Dadurch wird sichtbar, welche Geräte erfolgreich waren und wo Probleme auftraten.

Nicht sofort alle Geräte gleichzeitig ändern

Auch im Lab sollte der Rollout schrittweise erfolgen. Zuerst ein Gerät, dann eine kleine Testgruppe, erst danach alle Zielsysteme. Diese einfache Vorsicht ist eine wichtige Best Practice, die später im Produktivbetrieb enorm wichtig wird.

• Einzelgerät testen
• Kleine Gruppe testen
• Dann Vollausrollung

So werden Fehler früh entdeckt, bevor sie auf alle Systeme wirken.

Das Projekt sinnvoll erweitern

Zusätzliche Standardblöcke ergänzen

Wenn der Grundprozess stabil ist, kann das Projekt im Lab fachlich erweitert werden. Die wichtigste Regel dabei: immer nur einen kleinen Standardbereich nach dem anderen hinzufügen.

• Zusätzliche Syslog-Hosts
• NTP-Authentifizierungsparameter
• SNMP- oder Management-Grundlagen
• Standortabhängige Banner oder Kontakttexte

Durch diese schrittweise Erweiterung bleibt das Projekt beherrschbar.

Logging und Ergebniszusammenfassung ergänzen

Ein weiterer sinnvoller Ausbau ist eine kleine Ergebnisübersicht. Das Skript kann zum Beispiel protokollieren, welche Geräte erfolgreich konfiguriert wurden und welche nicht.

• Erfolgreiche Geräte zählen
• Fehlgeschlagene Geräte sichtbar auflisten
• Zeitpunkt des Rollouts notieren

So wächst das Mini-Projekt langsam in Richtung eines kleinen, echten Change-Werkzeugs.

Typische Fehler in diesem Mini-Projekt

Direkt mit mehreren Geräten starten

Ein häufiger Anfängerfehler ist, sofort eine ganze Gerätegruppe zu verändern. Das erhöht unnötig das Risiko und erschwert die Fehlersuche. Der erste Test sollte immer auf einem einzelnen Gerät erfolgen.

Keine Verifikation einbauen

Nur weil ein Skript Befehle ohne sichtbaren Fehler sendet, ist die Konfiguration noch nicht automatisch korrekt umgesetzt. Vorher- und Nachher-Prüfungen sind deshalb zentral.

Standard und Sonderfall vermischen

Ein weiteres häufiges Problem ist, dass versucht wird, zu viele Unterschiede in einem kleinen Projekt gleichzeitig abzubilden. Für den Einstieg sollte der Standardblock wirklich standardnah und möglichst gleichförmig sein.

Daten im Code hart verdrahten

Wenn Geräte und Konfigurationswerte fest im Skript stehen, sinkt die Wiederverwendbarkeit stark. Deshalb sollte möglichst früh mit Inventaren und später mit Templates gearbeitet werden.

Versionsverwaltung und saubere Entwicklung im Projekt

Git schon für kleine Rollout-Skripte einsetzen

Auch ein kleines Lab-Projekt profitiert von Versionsverwaltung. Gerade bei schreibender Automatisierung ist es sehr hilfreich, nachvollziehen zu können, wann der Standardblock, das Inventar oder die Rollout-Logik geändert wurden.

Ein einfacher Start:

git init
git add .
git commit -m "Initiales Mini-Projekt fuer Standardkonfiguration im Lab"

Dadurch lassen sich spätere Anpassungen deutlich klarer einordnen.

In kleinen Schritten entwickeln

Das Projekt sollte bewusst stufenweise aufgebaut werden.

• Erst ein Gerät
• Dann mehrere Geräte
• Dann Inventar auslagern
• Dann Template einführen
• Dann Pre- und Post-Checks ergänzen
• Dann Fehlerbehandlung ausbauen

Diese Reihenfolge macht das Projekt technisch und didaktisch deutlich robuster.

Best Practices für das Mini-Projekt „Standardkonfiguration im Netzwerk verteilen“

• Mit einem kleinen, risikoarmen Standardblock wie Banner, NTP oder Syslog beginnen.
• Vor jedem Rollout Managementzugang und SSH-Erreichbarkeit manuell verifizieren.
• Die Zielkonfiguration zuerst fachlich klar definieren und manuell an einem Gerät testen.
• Immer mit einem Einzelgerät starten, bevor mehrere Systeme geändert werden.
• Pre-Checks und Post-Checks bewusst in den Ablauf einbauen.
• Geräteinventar und Konfigurationslogik sauber voneinander trennen.
• Bei variablen Werten früh mit Templates statt mit festen Befehlslisten arbeiten.
• Fehlersituationen wie Timeout oder Authentifizierungsprobleme gezielt behandeln.
• Rollouts schrittweise ausweiten und nicht sofort auf alle Geräte gleichzeitig anwenden.
• Skripte, Templates und Inventare mit Git versionieren.

Dieses Mini-Projekt zeigt sehr anschaulich, wie aus einer kleinen Standardänderung ein echter Automatisierungsprozess wird. Die Verteilung einer Standardkonfiguration verbindet SSH-Zugriff, Inventare, Templates, Verifikation, Fehlerbehandlung und sauberes Change-Denken in einer Aufgabe, die im Lab gut kontrollierbar und gleichzeitig fachlich realistisch ist. Wer diesen Ablauf sauber umsetzt, lernt nicht nur ein paar Konfigurationszeilen automatisiert zu verteilen, sondern entwickelt ein tragfähiges Verständnis dafür, wie wiederkehrende Netzwerkstandards strukturiert, überprüfbar und sicher ausgerollt werden können.

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.