Erst lesen, dann sichern, dann prüfen, zuletzt ändern

Warum der Einstieg nur lesend sein sollte

Ein lesendes Playbook kann im schlimmsten Fall eine SSH-Sitzung belegen. Ein schreibendes kann die Management-Schnittstelle abschalten, ein VLAN auf einem Trunk entfernen oder die Startkonfiguration überschreiben. Die Ansible-Dokumentation warnt beim Zustand overridden ausdrücklich, dass du dir damit den Zugang zum Gerät nehmen kannst, etwa wenn die Konfiguration des Management-Interfaces überschrieben wird.

Die lesenden Stufen haben einen zweiten Zweck: Sie zeigen, wie heterogen das Netz wirklich ist. Unterschiedliche Softwarestände, Plattformen mit abweichender Befehlssyntax, Geräte ohne SSH oder mit veralteten Schlüsselverfahren und vergessene Ports im Status err-disabled fallen beim Lesen auf. Jeder dieser Funde wäre beim ersten schreibenden Lauf zu einem Fehler geworden.

Stufe 1 und 2 als Code: Inventar, Fakten, Backup

Das Inventar trennt Geräte nach Plattform und Rolle, die Gruppenvariablen enthalten die Verbindungsdaten. Die Werte für Benutzer und Kennwort kommen aus einer Vault-Datei. Mit ansible-inventory --graph prüfst du, ob die Gruppen so aufgebaut sind, wie du denkst.

Das Backup-Playbook ist bewusst schlicht. Wer das Backup zusätzlich als Teil eines späteren Änderungs-Playbooks braucht, kann bei cisco.ios.ios_config die Option backup setzen; das Modul sichert dann vor der Änderung die vollständige laufende Konfiguration.

# inventory/hosts.yml
all:
  children:
    ios:
      children:
        access_muc:
          hosts:
            sw-muc-e1:
              ansible_host: 10.0.10.11
            sw-muc-e2:
              ansible_host: 10.0.10.12

# group_vars/ios.yml
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: cisco.ios.ios
ansible_user: svc-ansible
ansible_password: "{{ vault_ios_password }}"
ansible_become: true
ansible_become_method: enable
ansible_become_password: "{{ vault_ios_enable }}"

# fakten.yml
- name: Softwarestand erfassen
  hosts: ios
  gather_facts: false
  tasks:
    - name: Fakten lesen
      cisco.ios.ios_facts:
        gather_subset: min
    - name: Zeile für den Bericht
      ansible.builtin.debug:
        msg: "{{ inventory_hostname }};{{ ansible_net_model }};{{ ansible_net_serialnum }};{{ ansible_net_version }}"

# backup.yml
- name: Konfigurationen sichern
  hosts: ios
  gather_facts: false
  tasks:
    - name: Running-Config ablegen
      ansible.netcommon.cli_backup:
        dir_path: /srv/netz-configs/ios
        filename: "{{ inventory_hostname }}.cfg"

Backups in Git ohne Rauschen

Ein Backup-Repository ist nur nützlich, wenn ein Diff eine echte Änderung bedeutet. Cisco-Konfigurationen enthalten Kommentarzeilen mit dem Zeitpunkt der letzten Änderung und des letzten Speicherns, auf älteren Plattformen auch Zeilen wie ntp clock-period, die sich ohne Zutun ändern. Entferne solche Zeilen vor dem Commit mit einem kleinen Filter, dann zeigt die Historie nur noch, was jemand tatsächlich konfiguriert hat.

Weil die Dateien Kennwort-Hashes, SNMP-Communities und Schlüssel enthalten, gehört das Repository in einen geschützten Bereich mit wenigen Leserechten. Spiegle es nicht in öffentliche oder breit freigegebene Plattformen. Ist doch einmal ein Geheimnis in einer Datei gelandet, die zu viele sehen, reicht Löschen im nächsten Commit nicht, weil es in der Historie bleibt.

#!/bin/sh
set -eu
cd /srv/automation
ansible-playbook -i inventory/hosts.yml backup.yml
cd /srv/netz-configs
sed -i -e '/^! Last configuration change/d' \
       -e '/^! NVRAM config last updated/d' \
       -e '/^ntp clock-period/d' ios/*.cfg
git add -A
git diff --cached --quiet || git commit -m "Backup $(date +%F)"

Stufe 3: Abweichungen vom Standard sichtbar machen

Die Soll-Ist-Prüfung braucht eine Definition des Solls. Für den Anfang reicht eine Vorlage mit den Zeilen, die auf jedem Gerät gleich sein müssen. ios_config vergleicht die laufende Konfiguration mit dieser Vorlage, wenn du diff_against auf intended setzt, und zeigt die Unterschiede beim Lauf mit --diff. Laut Dokumentation ändert dieser Aufruf das Gerät nicht.

Für Prüfungen mit Logik, etwa ob jeder Access Port BPDU Guard hat oder ob kein Trunk VLAN 1 als Native VLAN nutzt, sind die strukturierten Daten der Resource-Module besser geeignet. Mit state: gathered bekommst du die Konfiguration als Datenstruktur und prüfst sie mit assert. Das Ergebnis lässt sich als Bericht ausgeben und in einen wöchentlichen Lauf einbauen.

- name: Standardkonfiguration prüfen
  hosts: ios
  gather_facts: false
  tasks:
    - name: Laufende Konfiguration gegen Sollvorlage vergleichen
      cisco.ios.ios_config:
        diff_against: intended
        intended_config: "{{ lookup('ansible.builtin.template', 'soll/basis.j2') }}"

    - name: VLANs strukturiert lesen
      cisco.ios.ios_vlans:
        state: gathered
      register: vlans

    - name: VLAN 30 muss vorhanden sein
      ansible.builtin.assert:
        that: "30 in (vlans.gathered | map(attribute='vlan_id') | list)"
        fail_msg: "VLAN 30 fehlt auf {{ inventory_hostname }}"

# Aufruf: ansible-playbook -i inventory/hosts.yml compliance.yml --diff

Stufe 4: Änderungen mit Resource-Modulen, Check-Modus und Review

Resource-Module wie ios_vlans, ios_interfaces oder ios_l2_interfaces beschreiben den gewünschten Zustand als Daten. Der Zustand merged ergänzt die vorhandene Konfiguration, replaced ersetzt die genannten Objekte, overridden ersetzt alles der Ressource, deleted entfernt. Für den Einstieg ist merged die sichere Wahl, weil nichts verschwindet, was nicht im Playbook steht.

Bevor ein Playbook ein Gerät ändert, durchläuft es drei Prüfungen. state: rendered erzeugt die Befehle offline, sodass ein Kollege sie im Merge Request lesen kann. Der Lauf mit --check und --diff gegen ein Gerät zeigt, was sich dort ändern würde, sofern das Modul den Check-Modus unterstützt. Und serial begrenzt die Zahl der Geräte, die gleichzeitig geändert werden.

- name: VLAN 30 für Telefonie anlegen
  hosts: access_muc
  gather_facts: false
  serial: 2
  tasks:
    - name: VLAN setzen
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 30
            name: VOICE
            state: active
        state: merged

    - name: In die Startkonfiguration schreiben, wenn geändert
      cisco.ios.ios_config:
        save_when: modified

# Vorschau an einem Gerät
# ansible-playbook -i inventory/hosts.yml vlan30.yml --check --diff --limit sw-muc-e1

Ansible oder Python mit Netmiko und NAPALM

Ansible, Netmiko und NAPALM sind keine Gegensätze, sondern Werkzeuge für unterschiedliche Ebenen. Netmiko ist eine Python-Bibliothek, die SSH-Sitzungen zu Netzgeräten vieler Hersteller vereinfacht: Befehle senden, Ausgaben lesen, Konfigurationszeilen schicken. NAPALM legt eine einheitliche Schnittstelle über mehrere Plattformen, mit Gettern für Fakten und Funktionen zum Laden, Vergleichen, Übernehmen und Zurückrollen von Konfigurationen. Für Cisco IOS nutzt der NAPALM-Treiber selbst Netmiko und setzt laut Dokumentation einen aktivierten SCP-Server und ein konfiguriertes Archiv voraus.

Die Entscheidung folgt zwei Fragen: Wer pflegt den Code, und wie viel Logik steckt darin? Ein Netzwerkteam ohne Programmiererfahrung kommt mit Ansible weiter, weil Playbooks lesbar sind und die Module Idempotenz mitbringen. Sobald eine Aufgabe Schleifen über Daten aus mehreren Systemen, Fehlerbehandlung mit Wiederholungen oder eigene Berichte braucht, wird Python übersichtlicher. Viele Teams kombinieren beides und rufen aus Ansible eigene Python-Module oder Skripte auf.

Prüfpunkte und Rollback

Ein automatischer Lauf braucht dieselben Sicherungen wie eine Änderung von Hand, nur konsequenter. Vor jedem schreibenden Lauf liegt ein Backup vor, das nicht älter als der Lauf ist. Es gibt einen Zugang zu den Geräten, der nicht von der Änderung abhängt, etwa ein Out-of-Band-Netz oder Konsolenserver. Und es ist vorher festgelegt, woran du erkennst, dass eine Welle erfolgreich war.

Für den Rückweg auf IOS XE gibt es zwei Mechanismen. Mit configure replace und einer gesicherten Datei setzt du die Konfiguration auf einen früheren Stand zurück. Mit dem Parameter time stellt das Gerät die vorherige Konfiguration selbst wieder her, wenn du die Änderung nicht rechtzeitig mit configure confirm bestätigst; das schützt vor dem Fall, dass du dich mit einer Änderung aussperrst. NAPALM nutzt für IOS denselben Mechanismus, um bei Fehlern automatisch zurückzurollen.

• Vor dem Lauf liegen ein frisches Backup und ein freigegebener Change vor, und der Out-of-Band-Zugang ist getestet.

• Die erste Welle umfasst ein Testgerät und ein produktives Gerät mit geringer Bedeutung.

• Nach jeder Welle prüfst du Erreichbarkeit, Nachbarschaften und die betroffene Funktion.

• Schon ein fehlgeschlagenes Gerät stoppt den Lauf, deshalb hältst du max_fail_percentage oder serial klein.

• Nach dem Lauf wiederholst du die Soll-Ist-Prüfung und nutzt erst dann save_when.

! Vor der Änderung: aktuellen Stand lokal ablegen
copy running-config flash:vor-change.cfg

! Neue Konfiguration mit Bestätigungsfrist von 10 Minuten einspielen
configure replace flash:neu.cfg time 10
! ... prüfen, dann bestätigen
configure confirm

! Sofort zurück auf den alten Stand
configure replace flash:vor-change.cfg