Konfig-Automation: Cisco Switches mit Ansible effizient verwalten

Konfigurations-Automation mit Ansible reduziert manuelle Fehler, beschleunigt Rollouts und macht Änderungen reproduzierbar. Statt „per Hand“ auf dutzenden Cisco Switches VLANs, Trunks, SSH oder Syslog zu konfigurieren, definierst du gewünschte Zustände als Code und lässt Ansible diese konsistent umsetzen. Besonders im Campus-Betrieb ist das hilfreich: Standards (Templates), sichere Changes (Check/Diff), Backups und ein klarer Audit-Trail werden plötzlich einfach.

Was Ansible bei Cisco Switches praktisch leistet

Ansible verbindet sich typischerweise per SSH (CLI) oder über APIs (z. B. NETCONF/RESTCONF bei IOS XE). Für viele Umgebungen reicht CLI-Automation vollkommen aus: Befehle ausführen, Konfiguration setzen, Unterschiede prüfen und Änderungen dokumentieren.

• Read-Only Audits: show-Befehle ausführen und Ergebnisse sammeln
• Konfiguration ausrollen: Standards/Templates auf viele Geräte anwenden
• Idempotenz: gleiche Playbooks laufen mehrfach ohne „Konfig-Müll“ zu erzeugen
• Backups und Diffs: Änderungen nachvollziehbar machen
• Change-Sicherheit: Check-Mode, Limit auf Teilmengen, Rollback-Strategien

Voraussetzungen: So bereitest du deine Umgebung vor

Für Cisco Automation brauchst du eine saubere Management Plane: SSH, stabile Management-IP, ACLs und passende Credentials. Ansible sollte aus einem Admin-Netz (Jump Host) arbeiten, nicht aus Client-VLANs.

• SSH v2 aktiv, Telnet deaktiviert, VTY-ACL gesetzt
• Lokaler Break-Glass-User oder AAA mit Fallback
• Erreichbarkeit der Management-IP (MGMT-VLAN/VRF)
• Git-Repo für Playbooks/Templates und ein klares Naming

Basis-Checks auf dem Switch

show ip interface brief
show running-config | include ip ssh|line vty|transport input
show version

Ansible Grundsetup: Inventory, ansible.cfg und Verbindungsprofil

Für Cisco IOS nutzt du in der Praxis häufig die Connection network_cli (SSH) und Module aus cisco.ios. Damit kannst du sowohl „show“-Kommandos als auch Konfigurationsblöcke ausrollen.

ansible.cfg (Minimal, praxisnah)

[defaults]
inventory = inventory.yml
host_key_checking = False
retry_files_enabled = False
stdout_callback = yaml
interpreter_python = auto
[ssh_connection]

pipelining = True

Inventory (YAML) mit Gruppen und Variablen

all:
  children:
    cisco_switches:
      hosts:
        sw-access-01:
          ansible_host: 10.1.99.11
        sw-access-02:
          ansible_host: 10.1.99.12
      vars:
        ansible_user: netops
        ansible_password: "{{ vault_netops_password }}"
        ansible_network_os: cisco.ios.ios
        ansible_connection: ansible.netcommon.network_cli
        ansible_become: true
        ansible_become_method: enable
        ansible_become_password: "{{ vault_enable_password }}"

Best Practice: Secrets nicht im Klartext (Ansible Vault)

ansible-vault create group_vars/cisco_switches/vault.yml
ansible-vault edit group_vars/cisco_switches/vault.yml

Read-Only Automation: Show-Kommandos standardisiert ausführen

Ein sehr guter Einstieg ist ein Audit-Playbook: Du sammelst „show“-Outputs von vielen Switches, ohne etwas zu verändern. Das ist ideal für Inventarisierung, Compliance und Troubleshooting.

Playbook: Basis-Audit (IOS)

- name: Cisco Switch Audit
  hosts: cisco_switches
  gather_facts: false
  tasks:
    - name: Show version
      cisco.ios.ios_command:
        commands:
          - show version
          - show interfaces status
          - show interfaces trunk
          - show spanning-tree summary
      register: audit_out
Code
- name: Save output locally
  ansible.builtin.copy:
    content: "{{ audit_out.stdout | to_nice_yaml }}"
    dest: "outputs/{{ inventory_hostname }}_audit.yml"


Ausführen (gezielt und sicher)
ansible-playbook audit.yml --limit sw-access-01
ansible-playbook audit.yml --limit cisco_switches

Konfiguration ausrollen: Idempotent mit ios_config
Für Standard-Configs (SSH, NTP, Syslog, Hardening-Basics) ist ios_config ein bewährter Ansatz. Du definierst Lines und Ansible sorgt dafür, dass sie vorhanden sind.
Playbook: Syslog + NTP Standard
- name: Standardize NTP and Syslog
  hosts: cisco_switches
  gather_facts: false
  vars:
    mgmt_vlan: 99
    ntp_servers:
      - 10.1.99.30
      - 10.1.99.31
    syslog_hosts:
      - 10.1.99.70
      - 10.1.99.71
  tasks:
    - name: Apply NTP/Syslog baseline
      cisco.ios.ios_config:
        lines:
          - clock timezone CET 1 0
          - clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
          - service timestamps log datetime msec
          - service timestamps debug datetime msec
          - "ntp source vlan {{ mgmt_vlan }}"
          - "logging source-interface vlan {{ mgmt_vlan }}"
          - logging trap notifications
          - logging buffered 8192
        parents: []
      notify: save_config
Code
- name: Configure NTP servers
  cisco.ios.ios_config:
    lines: "{{ ntp_servers | map('regex_replace', '^(.*)$', 'ntp server \1') | list }}"
  notify: save_config

- name: Configure Syslog hosts
  cisco.ios.ios_config:
    lines: "{{ syslog_hosts | map('regex_replace', '^(.*)$', 'logging host \1') | list }}"
  notify: save_config

handlers:

- name: save_config

cisco.ios.ios_config:

save_when: modified


Warum das „sicherer“ ist als Copy/Paste

Einheitliche Standards auf allen Geräten
Wiederholbar (idempotent) ohne doppelte Konfigzeilen
Änderungen werden nur gespeichert, wenn wirklich modifiziert wurde

Templates statt Lines: Standards sauber pflegen
Wenn Konfigurationen wachsen, sind Templates sinnvoll: Du pflegst eine „Golden Config“ pro Rollenprofil (Access, Distribution) und variierst nur wenige Parameter (Hostname, MGMT-IP, VLAN-Listen).
Jinja2 Template Beispiel (Auszug)
hostname {{ hostname }}
ip domain-name {{ domain_name }}
ip ssh version 2

ip ssh time-out 60

ip ssh authentication-retries 3
logging source-interface vlan {{ mgmt_vlan }}

{% for host in syslog_hosts %}

logging host {{ host }}

{% endfor %}
ntp source vlan {{ mgmt_vlan }}

{% for s in ntp_servers %}

ntp server {{ s }}

{% endfor %}



Template ausrollen
- name: Deploy baseline template
  hosts: cisco_switches
  gather_facts: false
  tasks:
    - name: Render template to running-config
      cisco.ios.ios_config:
        src: "templates/baseline.j2"
      notify: save_config

Backups und Restore: Konfig-Sicherung automatisieren
Vor Changes ist ein Backup Pflicht. Mit Ansible kannst du Running-Config ziehen, versionieren und bei Bedarf vergleichen. Das ist die Basis für Rollback-Prozesse.
Running-Config sichern
- name: Backup running-config
  hosts: cisco_switches
  gather_facts: false
  tasks:
    - name: Get running-config
      cisco.ios.ios_command:
        commands:
          - show running-config
      register: run_cfg
Code
- name: Store backup
  ansible.builtin.copy:
    content: "{{ run_cfg.stdout[0] }}"
    dest: "backups/{{ inventory_hostname }}_running.cfg"


Restore (kontrolliert, als Change)
- name: Restore configuration snippet
  hosts: cisco_switches
  gather_facts: false
  tasks:
    - name: Push known-good snippet
      cisco.ios.ios_config:
        src: "restore_snippets/{{ inventory_hostname }}.cfg"
        match: none
      notify: save_config

Change-Sicherheit: Check Mode, Diff und Limit nutzen
Automation ist nur dann betriebssicher, wenn du Änderungen kontrolliert ausrollst. Nutze Check-Mode, Diffs und Rollouts in Wellen (z. B. erst ein Switch, dann ein Stack, dann Standort).
Dry-Run und Diff
ansible-playbook ntp_syslog.yml --check --diff --limit sw-access-01
ansible-playbook ntp_syslog.yml --check --diff --limit cisco_switches

Rollout in Etappen
ansible-playbook ntp_syslog.yml --limit "sw-access-01,sw-access-02"

Typische Stolperfallen und wie du sie vermeidest
Viele Automation-Probleme entstehen nicht durch Ansible, sondern durch inkonsistente Switch-Basics oder fehlende Standards.

SSH/AAA instabil: Management-Plane vorher härten und testen
Enable/Privilege Probleme: ansible_become korrekt setzen
Konfig driftet: Templates + Git + Reviews statt ad-hoc Lines
Zu breite Changes: immer --limit und Check/Diff zuerst
Fehlende Rollback-Strategie: Backups vor jedem Rollout

Operativer Betrieb: Git, Reviews und Standard-Workflows
Der größte Gewinn entsteht, wenn du „Netzwerk als Code“ auch organisatorisch lebst: Änderungen per Pull Request, einheitliche Templates, automatisierte Checks und klare Freigaben.

Git-Repo als Single Source of Truth für Standards und Templates
Pull Requests mit Review (Vier-Augen-Prinzip)
Check-Mode + Diff als Pflicht vor Merge/Rollout
Backups und Outputs als Artefakte (Audit-Trail)

Standard-Kommandoblock für den Alltag
ansible-playbook audit.yml --limit sw-access-01
ansible-playbook baseline.yml --check --diff --limit sw-access-01
ansible-playbook baseline.yml --limit sw-access-01

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze


Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)


Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)


Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation


Optional Security: Basic ACLs und SSH-Hardening


Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)


Sie erhalten


✅ Packet Tracer .pkt Datei


✅ Saubere Konfigurations-Notizen pro Gerät


✅ Verifikations-Checkliste + erwartete Outputs


✅ Kurze Dokumentation (wie die Topologie funktioniert)


  Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.