Automatización de redes con Ansible: Playbooks para la configuración de switches, copias de seguridad y reversión

La automatización de red con Ansible es, en muchos equipos de TI, la clave para hacer que los cambios recurrentes en switches, las copias de seguridad periódicas de configuración y los procesos de retroceso controlados sean reproducibles y auditables. Este howto práctico está dirigido a administradores, system engineers y operadores y explica paso a paso los requisitos previos, las trampas típicas, ejemplos concretos de playbooks y estrategias seguras de verificación y recuperación.

¿Por qué automatizar la red? Objetivos y breve definición de términos

La automatización de red reduce errores manuales, acelera los despliegues y mejora la trazabilidad. En este artículo usamos Ansible como herramienta de orquestación. Ansible es una herramienta de automatización sin agentes: el nodo de control (Ansible‑Control‑Node) se conecta por SSH o mediante plugins de conexión específicos para redes con los dispositivos y ejecuta tareas declarativas (playbooks).

Términos importantes en una frase: Playbook (archivo YAML con tareas), Inventory (lista de dispositivos), Connection Plugins (p. ej. network_cli para switches), idempotencia (repetibilidad sin efectos secundarios) y Rollback (restauración de una configuración previa).

Resumen breve de los requisitos de operación

• Nodo de control: Ansible 2.15+ o una versión moderna 2.x; Python y las Collections necesarias (p. ej. ansible.netcommon, community.general, y, si procede, colecciones del fabricante como cisco.ios).
• Acceso: acceso SSH con permisos suficientes (opcionalmente contraseña de enable/privilege). Los dispositivos de red deben ser accesibles desde el Control‑Node.
• Inventario: Inventories y group_vars bien organizados para credenciales; secretos gestionados mediante Ansible Vault o un backend de secretos (p. ej. HashiCorp Vault).
• Entorno de pruebas: laboratorio o staging con uno o pocos dispositivos para validar los playbooks antes de introducirlos en producción.

Automatización de red con Ansible: estructura básica del Inventory

Un inventory comprensible es la base. Aquí un ejemplo INI sencillo que muchos equipos aún usan:

[switches]
sw-core-01 ansible_host=10.0.1.10 ansible_network_os=ios
sw-access-01 ansible_host=10.0.1.20 ansible_network_os=ios

[all:vars]
ansible_user=netadmin
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Explicación: ansible_network_os ayuda a Ansible a seleccionar el módulo/gestión de prompts adecuados; network_cli es el plugin de conexión para switches basados en CLI. Preferentemente, los datos sensibles (contraseñas, claves SSH) no deberían estar en el inventory, sino gestionarse mediante Vault o un gestor de credenciales de Ansible.

Playbook: recopilar copia de seguridad de la configuración

Las copias de seguridad son el componente más subestimado. Aquí un playbook robusto que recupera la configuración en ejecución y la guarda localmente en el Control‑Node. Utiliza el módulo genérico ansible.netcommon.cli_command (funciona con muchos fabricantes) y almacena la salida mediante una acción local.

---
- name: Collect running-config backups from switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Get running configuration
      ansible.netcommon.cli_command:
        command: show running-config
      register: running_cfg

    - name: Ensure backup directory exists on control node
      local_action:
        module: file
        path: "backups/{{ inventory_hostname }}"
        state: directory
        mode: '0750'

    - name: Save running configuration to control node
      local_action:
        module: copy
        content: "{{ running_cfg.stdout[0] | default('') }}n"
        dest: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic }}.cfg"
        mode: '0640'

¿Por qué así? El playbook separa los datos del dispositivo (obtenidos por SSH) y el almacenamiento de las copias de seguridad (local en el nodo de control). Esto facilita la revisión, el control de versiones y el archivado seguro. Preste atención al formato de marca temporal (ISO8601) y a los modos de archivo seguros.

Comprobar antes de iniciar

• Comprobar el acceso de prueba: ejecute un comando ad‑hoc simple:

ansible switches -m ansible.netcommon.cli_command -a "command='show version'" -i inventory.ini

Si eso falla, compruebe: versión de Ansible, Connection‑Plugin, acceso a la red, credenciales y detección del prompt (timeout, enable-password).

Playbook: Cambio de configuración (Push) con Diff y Check‑Mode

Para los playbooks de cambio debería utilizar enfoques modulados y, en la medida de lo posible, idempotentes. Muchas collections de fabricantes (p. ej. cisco.ios.ios_config) implementan lógicas idempotentes. Si eso no es posible, utilice cli_config con –check o las opciones de diff.

---
- name: Deploy interface description to access switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Apply interface configuration lines
      ansible.netcommon.cli_config:
        lines:
          - interface GigabitEthernet1/0/48
          - description "PRD: uplink to router"
          - switchport mode access
          - switchport access vlan 100
      register: cfg_result

    - name: Show diff when changed
      debug:
        var: cfg_result.diff

Ejecute las operaciones primero en un único grupo de dispositivos de prueba y luego en lotes. Al probar, utilice ansible-playbook --check --diff para minimizar riesgos; tenga en cuenta que no todos los módulos de red soportan completamente el Check‑Mode.

Estrategias de rollback: tipos e implementación

El rollback no es un proceso de un solo clic para todos los dispositivos. Existen tres enfoques pragmáticos:

1. Restauración nativa del proveedor (recomendado): utilice funciones propias del dispositivo como configure replace (soportado por muchos Cisco IOS‑XEs) o los rollbacks de Junos. Suelen ser atómicos y minimizan transiciones inconsistentes.
2. Push del último backup conocido bueno: cargue el archivo de backup y escriba línea por línea mediante cli_config. Es más aplicable en general, pero puede generar estados intermedios inconsistentes.
3. Comparación de configuraciones y revert selectivo: identifique únicamente las líneas modificadas y aplique correcciones selectivas. Más laborioso, pero menos arriesgado en entornos heterogéneos.

Ejemplo: rollback simple (push del archivo guardado)

---
- name: Rollback config by pushing saved file content
  hosts: switches
  gather_facts: no
  connection: network_cli
  vars:
    rollback_file: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-20260728T120000Z.cfg"
  tasks:
    - name: Read rollback file on control node
      local_action:
        module: slurp
        src: "{{ rollback_file }}"
      register: rollback_raw

    - name: Decode rollback content
      set_fact:
        rollback_text: "{{ rollback_raw.content | b64decode }}"

    - name: Apply rollback configuration via CLI
      ansible.netcommon.cli_config:
        lines: "{{ rollback_text.split('n') }}"
      register: rb_result

    - name: Debug apply result
      debug:
        var: rb_result

Atención: Este método escribe prácticamente todas las líneas. Pruébelo en un entorno de laboratorio. Surgen problemas si la copia de seguridad guardada contiene comandos de consola propietarios, estados temporales de interfaces o entradas no persistentes.

Sichere Betriebsregeln und Checkliste vor Änderungen

Antes de cualquier cambio, las siguientes comprobaciones deberían automatizarse o documentarse:

• Copia de seguridad existente y probada (ver Playbook).
• Ventana de cambio definida y partes interesadas informadas.
• Ejecución de prueba en modo Check o en un dispositivo de staging.
• Serialidad: desplegar cambios en lotes pequeños (serial: 1–5 en Ansible) para evitar fallos masivos.
• Validación: tras el cambio ejecutar comprobaciones automatizadas (Ping, BGP‑Neighbors, VLAN‑Membership).
• Playbook de rollback disponible y procedimiento de RESTauración probado.

Typische Stolperfallen und wie Sie sie lösen

1) Authentifizierungs‑ und Prompt‑Probleme

Síntomas: Timeouts, prompts inesperados, faltan privilegios de Enable. Causas: ansible_connection incorrecto, falta de privilege escalation, diferentes Prompt‑Strings. Solución: ajustar group_vars para ansible_become, ansible_become_password o usar claves SSH y realizar una prueba ad‑hoc de verificación con show version. Configure, si es necesario, los parámetros de timeout y verifique los Prompt‑Strings interactivos en ansible.cfg.

2) fehlende Idempotenz

Si usa comandos CLI en bruto, las acciones a menudo no son idempotentes (cambio en cada ejecución). Mejor: módulos de configuración específicos del proveedor (p. ej. cisco.ios.ios_config) que realizan conciliación de estado. Si eso no es posible, cree su propia lógica de comparación (diff antes/después, hashes).

3) Parallelität führt zu Netzstörungen

Los cambios masivos simultáneos pueden violar dependencias (p. ej. STP, LACP). Use en Ansible serial en sus plays o ejecuciones por roles mediante tags. Ejemplo:

- hosts: switches
  serial: 3
  tasks:
    - name: Apply change
      ...

4) Unvollständige Backups

Algunos dispositivos entregan solo partes de la configuración o requieren comandos especiales para la persistencia. Verifique las copias de seguridad regularmente mediante pruebas de RESTauración automatizadas en un laboratorio.

Validierung und Monitoring nach Änderung

Las comprobaciones automatizadas son obligatorias. Comprobaciones ejemplo que deberían ejecutarse inmediatamente tras un cambio:

• Accesibilidad ICMP para rutas críticas.
• Estado de vecinos (BGP/OSPF) de routers adyacentes.
• Verificación de VLAN y estado de puertos para los puertos de acceso afectados.
• Observar métricas SNMP/Telemetry (latencia, tasas de error) — las anomalías señalan problemas potenciales.

Un pequeño ejemplo de cómo implementar una comprobación post‑cambio como Playbook:

---
- name: Post-change validation
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Check interface up status
      ansible.netcommon.cli_command:
        command: show interfaces status
      register: intf_status

    - name: Fail if critical port is down
      fail:
        msg: "Critical interface down on {{ inventory_hostname }}"
      when: "'Gi1/0/48' in intf_status.stdout[0] and 'notconnect' in intf_status.stdout[0]"

Audit, Archivierung und Retention

Backups sollten versioniert, geprüft und archiviert werden. Empfehlenswert ist ein Ansatz mit Git‑Repository für Text‑Backups (nur für Konfigurationstexte) kombiniert mit Objekt‑Storage für Langzeitarchiv (z. B. S3). Prüfen Sie folgende Punkte:

• Integrität: regelmäßige Hash‑Checks.
• Retention‑Policy: gesetzliche/fraktionelle Aufbewahrungsfristen definieren.
• Zugriffskontrolle: wer darf RESTore auslösen? (Role‑Based Controls)

Praxisbeispiel: Minimaler Workflow für einen Change

1. Playbook in Repo aktualisieren, Merge Request mit Review durchführen.
2. Auf Staging‑Switch dry‑run (–check) ausführen.
3. Automatisches Backup vor Change erstellen.
4. Change in kleinen Batches mit Live‑Monitoring ausrollen.
5. Post‑Checks automatisch laufen lassen; bei Fehlern automatisches Rollback triggern.

Troubleshooting: Wichtige Prüfsequenz

1. Verbindungstest: ad‑hoc Aufgabe wie oben (show version).
2. Logs prüfen: Ansible verbose Mode -vvv zeigt SSH‑Dialog und Prompt‑Erkennung.
3. Prompt/Expect‑Probleme: Prüfen, ob Modulprompt (ansible_network_os) korrekt gesetzt ist.
4. Timeouts: erhöhen Sie ansible_connection_timeout in group_vars falls nötig.
5. Rollback vorher testen: Spielen Sie RESTore in einer isolierten Umgebung durch.

Netzwerkautomation mit Ansible: CI/CD, Secrets und Telemetrie integrieren

Integration in CI/CD‑Pipelines macht Changes nachvollziehbar und auditierbar. Ein typischer Ablauf ist: Merge Request → automatischer Lint/Unit‑Test der Playbooks → Dry‑Run in einem Lab → Genehmigungsstufe → sequenzielles Rollout. Nutzen Sie für Secrets Ansible Vault oder ein dediziertes Secret‑System (z. B. HashiCorp Vault). Vault erlaubt dynamische Credentials und reduziert das Risiko von long‑lived Passworten.

Telemetry (z. B. gNMI, streaming telemetry, SNMP Traps) ergänzt Automatisierung mit Echtzeit‑Metriken. Nach einem Change sollten Telemetry‑Alerts automatisch mit dem Change‑Context verbunden werden (Change‑ID, Run‑ID) — so erkennen Sie, ob ein Alarm durch die Änderung verursacht wurde.

Beispiel: CI‑Step, der ein Playbook im Check‑Mode ausführt

#!/bin/bash
# CI step: run playbook in check mode and fail on changes
ansible-playbook -i inventory.ini change_playbook.yml --check --diff
if [ $? -ne 0 ]; then
  echo "Check mode failed or would change devices" >&2
  exit 1
fi

Atomicere Rollbacks: Vendor‑native Replace

Wenn Ihre Plattform configure replace oder ein äquivalentes atomisches Replace‑Verfahren unterstützt, nutzen Sie es. Das reduziert die Gefahr von Zwischenzuständen. Beispiel für Cisco IOS‑XEs mit einem vendor‑Modul (conceptual example):

---
- name: Atomic replace from candidate file (vendor-specific)
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Replace running-config atomically
      cisco.ios.ios_config:
        src: "backups/{{ inventory_hostname }}/candidate.cfg"
        replace: yes
        save_when: modified

Nota: los parámetros se denominan de forma distinta según la colección. Revise la documentación de su vendor‑Collection y pruebe el procedimiento de forma intensiva en el entorno de laboratorio.

Monitorización: listas de verificación, conocimiento operativo y buenas prácticas

Para un funcionamiento sostenible son decisivos los mecanismos de monitorización y verificación. Recomendaciones:

• Pruebas automatizadas de RESTauración al menos trimestralmente en un entorno aislado.
• Comprobaciones de diferencias después de cada backup: genere un hash (p. ej., SHA256) y guárdelo como metadatos.
• Adjuntar el contexto del cambio a la monitorización: Run‑ID, Commit‑Hash, operador, número de ticket.
• Playbooks de alertas: ante alarmas críticas, rollback automático o desencadenamiento de escalación según la política.

Ejemplo: generación de hash y almacenamiento de metadatos después del backup:

sha256sum backups/sw-core-01/sw-core-01-20260728T120000Z.cfg > backups/sw-core-01/metadata.txt
echo "commit: $GIT_COMMIT" >> backups/sw-core-01/metadata.txt
echo "run_id: $CI_RUN_ID" >> backups/sw-core-01/metadata.txt

Runbook de emergencia: recuperación manual y acceso OOB

Si el rollback automático falla, se necesita un runbook claro. Resumen:

1. Comprobar la consola OOB (Console‑Server, IPMI/Redfish) — asegura el acceso cuando la red no es alcanzable.
2. Identificar la última copia de seguridad íntegra (comprobar metadatos: timestamp, SW‑Version).
3. Cargar el rollback localmente en la consola o aplicar mediante TFTP/USB.
4. Comprobaciones básicas: interfaces ‚up‘, enrutamiento/vecinos, ACLs críticas.
5. Comprobaciones detalladas posteriores y cierre del ticket tras confirmar el éxito.

Conclusión: consejo práctico para la operación

La automatización de redes con Ansible aporta transparencia y velocidad — siempre que invierta en higiene del inventario, disciplina de backups, procedimientos de rollback probados y una estrategia de introducción gradual. Utilice módulos específicos del proveedor donde tenga sentido, automatice los scripts de validación y mantenga reglas estrictas de acceso y retención. En dispositivos heterogéneos, las estrategias pragmáticas de backup y rollback selectivo son la opción más segura.

Punto de partida concreto: cree un backup‑playbook como el anterior, pruébelo contra un switch de staging y luego amplíe paso a paso sus change‑playbooks con check‑mode, salidas diff y despliegues serializados. Complételo con CI/CD, integración de telemetría y pruebas de RESTauración periódicas para reducir de forma sostenible los riesgos operativos.

En este tema también son importantes los playbooks de Ansible y la configuración de switches. El artículo ordena estos aspectos de manera clara y muestra qué es relevante en la práctica diaria.