Das Wichtigste in Kürze
- Die cisco.ios-Collection (Stand: Version 11.5) bringt neben ios_config Ressourcen-Module wie ios_vlans und ios_interfaces mit — die Doku nennt das ausdrücklich deklaratives Management.
- Die States merged, replaced und overridden entscheiden, ob Soll ergänzt, ein Objekt exakt hergestellt oder die Gesamtmenge durchgesetzt wird — das ist der Schritt vom Kommando zum Zustand.
- Im Check-Modus führt Ansible nichts aus und meldet, was sich geändert hätte; der Diff-Modus zeigt Vorher/Nachher. Beides zusammen ist der Probelauf, der vor jedem Change steht.
- Die Offline-States rendered, parsed und gathered arbeiten ohne Zielgerät bzw. lesend — damit laufen Konfigurations-Checks in der Pipeline, nicht im Wartungsfenster.
Das Schleifen-Skript ist nicht falsch — es ist nur die falsche Abstraktion. Es beschreibt Tastendrücke, nicht Zustände. Ob VLAN 30 danach überall existiert, ob es irgendwo schon mit anderem Namen existierte, ob auf einem Gerät zusätzlich VLAN 99 vor sich hinlebt: Das Skript weiß es nicht, und sein Log auch nicht. Wer damit auditierbare Changes fahren will, liest hinterher vierzig Terminal-Mitschnitte.
Die cisco.ios-Collection (Stand: Version 11.5) löst das auf zwei Ebenen. Für die Übergangszeit gibt es ios_config — die Doku beschreibt es als Arbeiten mit IOS-Konfigurationssektionen „auf deterministische Weise“, inklusive einer Backup-Option, die vor jeder Änderung die komplette running-config des Geräts sichert. Und für die Ziel-Arbeitsweise gibt es die Ressourcen-Module: ios_vlans, ios_interfaces, ios_l2_interfaces, ios_l3_interfaces, dazu ios_ospfv2, ios_acls, ios_ntp_global und weitere — deklaratives Management statt Kommandoliste.
Merged, replaced, overridden: drei Verben, drei Verträge
Jedes Ressourcen-Modul nimmt denselben Parameter entgegen: state. Er legt fest, welchen Vertrag der Lauf mit dem Gerät schließt — und genau hier trennt sich Automatisierung von Skripterei:
| State | Vertrag mit dem Gerät |
|---|---|
| merged (Standard) | Das beschriebene Soll wird ergänzt; Bestehendes bleibt unangetastet |
| replaced | Die beschriebenen Objekte werden exakt so hergestellt, wie sie im Soll stehen |
| overridden | Die Gesamtmenge wird durchgesetzt — was nicht im Soll steht, fliegt |
| deleted / purged | Beschriebenes bzw. Aufgeräumtes wird entfernt |
Idempotenz ist dabei kein Zusatzfeature, sondern die Folge: Wer Zustände beschreibt, kann denselben Lauf zweimal starten — der zweite meldet schlicht keine Änderung. Genau daran lässt sich übrigens prüfen, ob ein Playbook sauber gebaut ist: Ein zweiter Lauf direkt nach dem ersten muss leer durchlaufen.
Kein Lauf ohne Probelauf
Ansible bringt die Betriebsart dafür mit: Im Check-Modus führt es auf den Zielsystemen nichts aus — Module, die ihn unterstützen, melden die Änderungen, die sie vorgenommen hätten. Der Diff-Modus liefert dazu die Vorher-Nachher-Sicht, und beide lassen sich kombinieren: erst ansehen, dann ausführen.
In der Praxis ist dieser Diff mehr als eine Vorsichtsmaßnahme: Er ist das Dokument, über das man vor dem Wartungsfenster sprechen kann — mit dem Kollegen, dem Kunden, dem Auditor. Der Change ist dann keine Ankündigung („wir passen die VLANs an“), sondern ein lesbarer Unterschied. Warum wir diese Artefakt-Disziplin für den Kern jeder Netzautomatisierung halten, steht im Beitrag über NetBox als Source of Truth — dort kommt das Soll her, gegen das der Diff hier entsteht.
Testbar ohne Produktionsnetz: die Offline-States
Der unterschätzte Teil der Ressourcen-Module sind die States, die kein Gerät verändern: rendered erzeugt aus den Soll-Daten die Konfiguration, ohne ein Gerät zu berühren; parsed macht aus vorhandenem Konfigurationstext strukturierte Daten; gathered liest den Ist-Zustand als Daten ein. Die Modul-Doku führt rendered und parsed ausdrücklich als Offline-Varianten.
- rendered in der Pipeline: Jede Änderung am Soll erzeugt die Zielkonfiguration im CI-Lauf — Reviewbar, bevor irgendetwas ein Gerät sieht.
- gathered als Drift-Wache: Ein wiederkehrender, rein lesender Lauf vergleicht Ist gegen Soll und macht aus „das sollte eigentlich so sein“ eine Ergebnisliste.
- parsed für den Bestand: Vorhandene Konfigurationen werden zu Daten — der ehrlichste Weg, ein gewachsenes Netz in die Soll-Welt zu überführen.
- Backup vor jedem Schreiben: Die ios_config-Backup-Option sichert die running-config, bevor sich etwas ändert — das Sicherheitsnetz kostet eine Zeile.
Vom Playbook zum abgenommenen Change
Die NTP-Pilotvorlage für Ansible trennt Eingaben, Diff und tatsächliche Zeitsynchronisation. Für den nächsten Schritt zeigt NetDevOps anhand einer gescheiterten Lab-Abnahme, warum ein erfolgreicher Konfigurationslauf keinen funktionierenden Dienst beweist.
Die Kette komplett
Zusammengesetzt ergibt das den Ablauf, den wir unter Netzwerkautomatisierung als Arbeitsweise beschreiben: Das Inventar kommt aus NetBox (dynamisch, mit Gruppen aus Standorten und Rollen), das Soll kommt aus der Source of Truth, rendered und der Check-Diff machen es lesbar, die Ressourcen-Module setzen es um — und gathered wacht danach über die Abweichung. Welche IOS-XE-Version dabei überhaupt auf die Geräte gehört, ist eine eigene Entscheidung mit eigenem Beitrag: IOS-XE-Versionsstrategie.
Quellen
Jede belegte Aussage dieses Beitrags ist hier nachvollziehbar. Das Abrufdatum sagt, wie frisch die Prüfung ist.
- Cisco Ios Collection (Version 11.5.0)öffnet in neuem Tab
Ansible Community Documentation · abgerufen am 27. August 2026
- cisco.ios.ios_vlans module — Resource module to configure VLANsöffnet in neuem Tab
Ansible Community Documentation · abgerufen am 27. August 2026
- cisco.ios.ios_config module — Manage Cisco IOS configuration sectionsöffnet in neuem Tab
Ansible Community Documentation · abgerufen am 27. August 2026
- Validating tasks: check mode and diff modeöffnet in neuem Tab
Ansible Community Documentation · abgerufen am 27. August 2026