Cisco 350-401: Automatización, Programabilidad y APIs — Guía de estudio

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNP Enterprise 350-401 ENCOR — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Cisco, o realiza tests cronometrados en ExamRoll.io.

Resumen

Las redes empresariales están pasando de la configuración dispositivo por dispositivo a operaciones basadas en controladores e impulsadas por la intención con automatización de ciclo cerrado. La programabilidad expone el estado y el control de la red a través de APIs y modelos de datos, mientras que herramientas como Python, Ansible y Git permiten flujos de trabajo repetibles y comprobables. El objetivo es expresar los resultados deseados de forma declarativa, hacer que los controladores traduzcan la intención en políticas y configuración, medir los resultados mediante telemetría y aseguramiento, y remediar las desviaciones automáticamente o con aprobación humana. Lograr esto requiere comprender los roles de los controladores, las APIs y los protocolos (REST, NETCONF/RESTCONF con YANG), los formatos de datos (JSON, XML, YAML), las plataformas de automatización (Cisco DNA Center) y las disciplinas operativas (idempotencia, control de versiones, pruebas, gestión de riesgos y reversión/rollback).

Controladores, Intención y Operaciones de Ciclo Cerrado

• Redes basadas en controladores y roles:
  • Cisco SD-WAN separa los planos: vManage proporciona el plano de gestión único; vSmart gestiona el plano de control y distribuye las políticas que dirigen el reenvío de datos a través del fabric; vBond orquesta la incorporación (onboarding) y puede actuar como un servidor STUN para atravesar NAT. Los routers de borde SD-WAN utilizan OMP como el protocolo del plano de control para comunicarse con vSmart.
  • Cisco SD‑Access crea una red superpuesta (overlay) que proporciona separación lógica de Capa 2 y Capa 3. Un nodo de plano de control del fabric mantiene una base de datos global de terminal a ubicación (endpoint-to-location), mientras que un nodo de borde del fabric conecta el fabric a redes externas. En redes inalámbricas, Radio Resource Management se ejecuta en el controlador inalámbrico.
• Intención y configuración declarativa:
  • La intención describe el resultado deseado, no cómo implementarlo en cada dispositivo. Los sistemas declarativos (por ejemplo, «segmentar a los invitados en todas partes con acceso solo a Internet») permiten a los controladores compilar la política en configuraciones específicas para cada dispositivo.
  • Compensaciones: Los modelos declarativos simplifican las operaciones y reducen la deriva (drift) de la configuración, pero pueden ocultar detalles de implementación. Los operadores necesitan herramientas transparentes para diferencias/vista previa (diff/preview) y reversión (rollback) para mantener la confianza.
• Operaciones de ciclo cerrado:
  • Medir: Recopilar el estado a través de telemetría por streaming y el aseguramiento del controlador.
  • Analizar: Detectar desviaciones de la intención (por ejemplo, violaciones de segmentación, caídas de SLA).
  • Actuar: Remediar mediante actualizaciones de políticas, cambios de configuración o ingeniería de tráfico.
  • Modos de fallo: Las tormentas de eventos o la telemetría ruidosa pueden desencadenar falsos positivos; los bucles de remediación pueden oscilar. Los mecanismos de protección (límites de tasa, histéresis, aprobaciones con intervención humana) y una correlación robusta evitan la degradación por sobrecarga (thrashing).

APIs, Modelos de Datos y Protocolos

• APIs REST:
  • Métodos: GET (leer), POST (crear/acción), PUT (reemplazar), PATCH (actualización parcial), DELETE (eliminar), HEAD/OPTIONS (metadatos).
  • Códigos de estado: 2xx éxito (200 OK, 201 Created), 3xx redirecciones, 4xx errores del cliente (400 bad input, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 429 rate limit), 5xx errores del servidor (500, 503).
  • Autenticación: Básica (sobre TLS), esquemas de token/portador (bearer) y OAuth 2.0. Utilice siempre TLS; evite incrustar credenciales en las URIs. Gestione la renovación y caducidad de los tokens.
  • Límites de tasa (Rate limits): Los servidores pueden limitar las solicitudes con un código 429 y la cabecera Retry-After. Implemente retroceso exponencial (exponential backoff), fluctuación (jitter) y seguimiento del presupuesto de solicitudes en los clientes.
• Formatos de datos y validación:
  • JSON es común para REST; XML sigue siendo predominante en NETCONF; YAML se utiliza para archivos escritos por humanos (inventarios, playbooks, conjuntos de variables). Convierta YAML a JSON internamente cuando sea necesario.
  • Validación de esquemas: Use JSON Schema para cargas útiles (payloads) JSON; XML Schema para XML; YANG para la gestión basada en modelos (tipos, restricciones, sentencias must/when). Valide en el lado del cliente antes de enviar para detectar errores de forma temprana.
• NETCONF, RESTCONF, YANG, RPCs y almacenes de datos (datastores):
  • Los modelos YANG definen estructuras de datos y operaciones para la configuración y el estado.
  • NETCONF utiliza XML sobre SSH, con operaciones como , , , , , . Los almacenes de datos (datastores) suelen incluir running y candidate; candidate permite un proceso de preparación y confirmación (prepare-and-commit) con atomicidad.
  • RESTCONF mapea los recursos modelados con YANG a una interfaz RESTful sobre HTTP(S), utilizando JSON o XML con tipos de medios (media types) estandarizados. Los métodos se corresponden con la semántica de NETCONF (PATCH/PUT para ediciones).
  • Modos de fallo y diseño:
    • Contención de bloqueos: Coordine el uso de para evitar interbloqueos (deadlocks); utilice un alcance limitado y tiempos de espera (timeouts).
    • Fallos parciales: Prefiera el datastore candidate + para cambios transaccionales. Si solo está disponible running, utilice grupos de cambio estructurados y puntos de control (checkpoints).
    • Deriva del modelo: Los dispositivos pueden soportar diferentes revisiones del módulo YANG; negocie las capacidades y realice pruebas durante la integración continua (CI).
• Ejemplos concisos:
  • Actualización parcial con RESTCONF (intercambio HTTP): PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 Content-Type: application/yang-data+json { “ietf-interfaces:interface”: { “name”: “GigabitEthernet1”, “description”: “Uplink”, “enabled”: true } }
  • NETCONF con Python (ncclient): from ncclient import manager cfg = """ GigabitEthernet1 Uplink true """ with manager.connect(host=“r1”, port=830, username=“netops”, password="***", hostkey_verify=False) as m: m.edit_config(target=“candidate”, config=cfg) m.commit()

Herramientas y flujos de trabajo: Python, Ansible, Git y pipelines

• Automatización con Cisco DNA Center:
  • Las API REST northbound proporcionan acceso al inventario, plantillas, aprovisionamiento y assurance. Las interfaces southbound conectan el controlador a los dispositivos (CLI, SNMP, NETCONF/RESTCONF) para ejecutar la intención.
  • Los flujos de trabajo de descubrimiento (discovery) pueden usar CDP, LLDP y rangos de IP. Utilice control de acceso basado en roles, plantillas basadas en proyectos y variables por sitio. Assurance correlaciona la telemetría para generar incidencias, puntuaciones de salud y remediaciones sugeridas, que son entradas clave para la automatización de ciclo cerrado (closed-loop).
• Fundamentos de Python para la automatización de redes:
  • Lenguaje principal: tipos, funciones, módulos, entornos virtuales y logging.
  • Librerías: requests/httpx (REST), ncclient (NETCONF), jinja2 (plantillas), pyyaml, json, pandas (manipulación de datos), rich/logging para observabilidad.
  • Prácticas: validación de entradas, reintentos con backoff, excepciones estructuradas, tiempos de espera (timeouts) y pruebas unitarias. Separe la lógica de negocio de las operaciones de E/S (I/O) para simplificar las pruebas.
• Ansible:
  • El inventario define hosts y grupos; mantenga host_vars/group_vars en formato YAML.
  • Los playbooks declaran el estado deseado; módulos como ios_config, ios_facts, iosxe_config, restconf_config y uri realizan las acciones. Use roles para encapsular lógica reutilizable.
  • Idempotencia: los módulos aseguran que ejecuciones repetidas converjan sin causar cambios no deseados. Use check_mode y diff para previsualizar; notifique a los handlers para guardar solo cuando haya cambios.
  • Ejemplo:
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Control de cambios: use ventanas de mantenimiento, una estrategia en serie o por lotes (batched), y limitación de velocidad (throttling) por sitio para limitar el radio de impacto (blast radius). Capture las comprobaciones pre y post-cambio automáticamente.
• Git, versionado, pruebas y pipelines:
  • Almacene la intención de la red (variables YAML, plantillas Jinja, playbooks), las configuraciones generadas y las pruebas en Git. Use ramas (branches), pull requests y revisión de código (code review). Los commits semánticos y las etiquetas (tags) alinean las versiones con los despliegues.
  • Pruebas (testing): haga linting de YAML y playbooks, valide esquemas YANG/JSON, ejecute pruebas unitarias y pruebas de escenario con Ansible Molecule. Integre pre-chequeos sintéticos (por ejemplo, de alcanzabilidad) en la CI.
  • Pipelines: Desarrollo → pre-producción/laboratorio (staging/lab) → canary en producción → despliegue por fases (phased rollout). Las puertas de control (gates) incluyen análisis estático, ejecuciones en seco (dry-runs) contra simuladores, aprobaciones y reversión (rollback) automática en caso de regresión en la salud del sistema.

Telemetría, automatización basada en eventos y gestión de riesgos

• Streaming de telemetría:
  • La telemetría dirigida por modelos (IOS XE, NX-OS) publica el estado modelado en YANG a intervalos definidos a través de gRPC/gNMI o NETCONF, con suscripciones dial-in o dial-out. Los beneficios incluyen baja latencia y datos estructurados, superando al scraping periódico de la CLI o al sondeo SNMP.
  • Ejemplo (IOS XE, conciso): telemetry ietf subscription 100 encoding gpbid filter xpath /interfaces-state/interface receiver ip 10.0.0.50 port 57500 protocol grpc-tcp
  • Consejos de diseño: alinear la frecuencia de muestreo con el caso de uso; asegurar la capacidad del bus de mensajes; diseñar pipelines de submuestreo (downsampling) y agregación; proteger contra la pérdida de telemetría con búferes y acuses de recibo (acknowledgments).
• Automatización basada en eventos:
  • Desencadenar acciones a partir de webhooks, syslog, traps de SNMP, eventos de DNA Center o temas de Kafka. Usar correlación y limitación de tasa (rate limiting) para evitar oscilaciones (flaps) inducidas por tormentas de eventos. Mantener manejadores (handlers) idempotentes que puedan reejecutarse de forma segura.
  • Bucle cerrado (closed-loop): un controlador detecta una infracción de política, valida con señales secundarias, abre un ticket de cambio o activa una remediación limitada, luego vuelve a medir y finaliza.
• Gestión de riesgos, rollback y credenciales:
  • Mecanismos de protección (guardrails): despliegues por fases (staged rollouts), límites de concurrencia, controles de radio de impacto (blast-radius), retroceso exponencial dinámico (dynamic backoff) ante respuestas 429/5xx y tiempos de espera (timeouts). Usar transacciones donde estén disponibles (NETCONF candidate + commit), o puntos de control (checkpoints) del dispositivo y configure replace.
  • Rollback: mantener configuraciones de referencia (golden configs), diferenciales (diffs) y puntos de control por dispositivo. Preferir la semántica commit-confirmed donde sea compatible; de lo contrario, implementar una reversión automatizada (fallback) usando temporizadores y verificaciones de alcanzabilidad.
  • Protección de credenciales: aplicar RBAC, tokens de corta duración y secretos just-in-time por trabajo. Usar almacenes de secretos (por ejemplo, Ansible Vault o una bóveda externa), nunca incrustar secretos en playbooks o en Git. Rotar las credenciales de forma programada y después de cambios de personal. Asegurar las credenciales del controlador al dispositivo y auditar el acceso.

Escenario de problema práctico

Aurelius Logistics planea estandarizar las configuraciones de campus y sucursales, aplicar una segmentación consistente e implementar aseguramiento en bucle cerrado (closed-loop assurance) usando Cisco DNA Center, al tiempo que habilita cambios seguros a través de Ansible y Git.

1. Establecer una línea base y descubrir la red

• Justificación: el descubrimiento de DNA Center usando rangos de IP más CDP/LLDP enumera dispositivos y topología, estableciendo un inventario autoritativo. Esto permite definir el alcance de la intención (intent scoping) y la herencia de variables por sitio. La recopilación de datos de aseguramiento (assurance) establece líneas base de salud previas al cambio para comparación y para los disparadores de rollback.

2. Modelar la intención y las plantillas en DNA Center

• Justificación: expresar la segmentación (p. ej., empleado, IoT, invitado) y las políticas de QoS de forma declarativa. Usar plantillas parametrizadas con variables de sitio para interfaces, enrutamiento y ACLs. La política declarativa permite al controlador compilar configuraciones específicas para cada dispositivo, reduciendo el error humano y la deriva de configuración (drift).

3. Implementar la gestión de configuración impulsada por Git

• Justificación: almacenar plantillas, variables de sitio (YAML) y pruebas de validación en Git. Las ramas de funcionalidad (feature branches) y las solicitudes de integración (pull requests) imponen la revisión por pares. Las etiquetas (tags) alinean los despliegues con las versiones, permitiendo un rollback preciso. Esto proporciona un historial de cambios auditable y soporta disparadores de pipeline automatizados.

4. Construir un pipeline de CI/CD con puertas de validación

• Justificación: las etapas del pipeline realizan linting de YAML, validan cargas útiles (payloads) JSON/YANG, hacen pruebas unitarias del renderizado de Jinja y simulan llamadas a la API en un sandbox. Los dry runs de DNA Center y los modos check_mode/diff de Ansible validan los cambios sin impacto. Solo al pasar todas las puertas, el pipeline permite la aprobación del operador para proceder.

5. Desplegar incrementalmente con Ansible y las APIs de DNA Center

• Justificación: usar las APIs northbound de DNA Center para enviar plantillas primero a un sitio canario (canary site), y luego desplegar en serie por sitio con límites de tamaño de lote. Para dispositivos que soportan NETCONF/RESTCONF, los módulos de Ansible realizan actualizaciones dirigidas e idempotentes. Este enfoque dual aprovecha el controlador para tareas pesadas de política y la automatización directa de dispositivos para cambios de grano fino, mientras se minimiza el radio de impacto.

6. Activar la telemetría por streaming y las verificaciones basadas en el aseguramiento

• Justificación: configurar la telemetría dirigida por modelos en los dispositivos de borde para alimentar DNA Center Assurance y la pila de observabilidad de la empresa. Definir SLOs (p. ej., tasa de éxito de incorporación, latencia) y suscripciones a eventos que generen alertas si las métricas posteriores al cambio empeoran. Esto permite la detección inmediata de resultados negativos.

7. Habilitar la remediación controlada en bucle cerrado

• Justificación: para desviaciones bien entendidas (p. ej., una interfaz caída con una solución alternativa conocida), permitir que el pipeline active un playbook restringido para revertir el último cambio o aplicar una corrección en caliente (hotfix). Requerir aprobación humana para remediaciones más amplias. Implementar retroceso exponencial (exponential backoff) y un período de enfriamiento (cooldown) para prevenir oscilaciones.

8. Preparar y probar las rutas de rollback

• Justificación: antes de cada cambio, crear puntos de control (checkpoints) del dispositivo o usar NETCONF candidate + commit-confirmed si está disponible. Archivar las configuraciones previas al cambio y etiquetar el repositorio de Git. Si las puntuaciones de salud caen o la telemetría muestra incumplimientos de SLA, el pipeline ejecuta configure replace o NETCONF discard/rollback, restaurando el estado anterior rápidamente.

9. Proteger las credenciales y aplicar el control de acceso

• Justificación: almacenar las credenciales de dispositivos/controladores en una bóveda; inyectar tokens de corta duración en los trabajos. Usar el RBAC de DNA Center para restringir los alcances de la API. Nunca registrar secretos en logs; limpiar las salidas en CI. Rotar credenciales y tokens regularmente y después de cambios de personal para reducir el riesgo.

10. Operacionalizar con documentación y runbooks

• Justificación: documentar las definiciones de intención, los esquemas de variables, los modos de fallo (límites de tasa, errores de API, desajustes de modelo) y los pasos de recuperación. Capacitar al NOC para interpretar las señales de aseguramiento y los estados del pipeline, asegurando respuestas consistentes y rápidas a los incidentes.

Este enfoque crea una ruta segura y comprobable desde la intención hasta la implementación, aprovecha los controladores para la distribución de políticas (con vManage/vSmart en SD‑WAN y DNA Center en el campus), utiliza herramientas idempotentes para la convergencia y cierra el bucle con validación respaldada por telemetría y remediación controlada.

← Seguridad Empresarial y Servicios de Identidad · Todos los dominios · Aseguramiento →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →