Cisco 350-401: Automazione, Programmabilità e API — Guida allo studio

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

Fa parte della Cisco CCNP Enterprise 350-401 ENCOR — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le reti aziendali stanno passando dalla configurazione dispositivo per dispositivo a operazioni basate su controller e guidate dall’intento (intent-driven) con automazione a ciclo chiuso (closed-loop). La programmabilità espone lo stato e il controllo della rete tramite API e modelli di dati, mentre strumenti come Python, Ansible e Git consentono flussi di lavoro ripetibili e testabili. L’obiettivo è esprimere i risultati desiderati in modo dichiarativo, far sì che i controller traducano l’intento in policy e configurazioni, misurare i risultati tramite telemetria e assurance, e rimediare automaticamente alle deviazioni o con l’approvazione umana. Per raggiungere questo obiettivo è necessario comprendere i ruoli dei controller, le API e i protocolli (REST, NETCONF/RESTCONF con YANG), i formati di dati (JSON, XML, YAML), le piattaforme di automazione (Cisco DNA Center) e le discipline operative (idempotenza, controllo di versione, test, gestione del rischio e rollback).

Controller, Intento e Operazioni a Ciclo Chiuso

• Networking basato su controller e ruoli:
  • Cisco SD-WAN separa i piani: vManage fornisce il singolo piano di gestione (management plane); vSmart gestisce il piano di controllo (control plane) e distribuisce le policy che dirigono l’inoltro dei dati attraverso la fabric; vBond orchestra l’onboarding e può agire come server STUN per attraversare il NAT. I router edge SD-WAN utilizzano OMP come protocollo del piano di controllo per comunicare con vSmart.
  • Cisco SD-Access crea una rete overlay che fornisce una separazione logica di Livello 2 e Livello 3. Un nodo del piano di controllo della fabric (fabric control-plane node) mantiene un database globale endpoint-to-location, mentre un nodo di confine della fabric (fabric border node) connette la fabric alle reti esterne. Nel wireless, il Radio Resource Management viene eseguito sul controller wireless.
• Intento e configurazione dichiarativa:
  • L’intento descrive il risultato desiderato, non come implementarlo su ciascun dispositivo. I sistemi dichiarativi (ad esempio, “segmentare gli ospiti ovunque con accesso solo a Internet”) consentono ai controller di compilare le policy in configurazioni specifiche per ogni dispositivo.
  • Compromessi: i modelli dichiarativi semplificano le operazioni e riducono il “drift” (deriva della configurazione), ma possono nascondere i dettagli di implementazione. Gli operatori necessitano di strumenti trasparenti per il confronto (diff/preview) e il rollback per mantenere la fiducia.
• Operazioni a ciclo chiuso:
  • Misurare: Raccogliere lo stato tramite telemetria in streaming e l’assurance del controller.
  • Analizzare: Rilevare deviazioni dall’intento (ad esempio, violazioni della segmentazione, cali di SLA).
  • Agire: Rimediare tramite aggiornamenti delle policy, modifiche alla configurazione o traffic engineering.
  • Modalità di fallimento: tempeste di eventi (event storm) o telemetria “rumorosa” possono innescare falsi positivi; i cicli di rimedio possono entrare in oscillazione. Meccanismi di protezione (guardrail) come rate limit, isteresi e approvazioni umane (human-in-the-loop), insieme a una correlazione robusta, prevengono il “thrashing” (sovraccarico instabile).

API, Modelli di Dati e Protocolli

• API REST:
  • Metodi: GET (lettura), POST (creazione/azione), PUT (sostituzione), PATCH (aggiornamento parziale), DELETE (rimozione), HEAD/OPTIONS (metadati).
  • Codici di stato: 2xx successo (200 OK, 201 Created), 3xx reindirizzamenti, 4xx errori del client (400 bad input, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 429 rate limit), 5xx errori del server (500, 503).
  • Autenticazione: Basic (su TLS), schemi basati su token/bearer e OAuth 2.0. Usare sempre TLS; evitare di incorporare credenziali negli URI. Gestire il rinnovo e la scadenza dei token.
  • Rate limit: I server possono applicare throttling con un codice 429 e l’header Retry-After. Implementare nei client exponential backoff, jitter e il tracciamento del budget di richieste.
• Formati di dati e validazione:
  • JSON è comune per REST; XML rimane prevalente in NETCONF; YAML è usato per file scritti da umani (inventari, playbook, set di variabili). Convertire internamente YAML in JSON quando necessario.
  • Validazione dello schema: Usare JSON Schema per i payload JSON; XML Schema per XML; YANG per la gestione basata su modelli (tipi, vincoli, istruzioni must/when). Validare lato client prima dell’invio per individuare precocemente gli errori.
• NETCONF, RESTCONF, YANG, RPC e datastore:
  • I modelli YANG definiscono strutture dati e operazioni per la configurazione e lo stato.
  • NETCONF utilizza XML su SSH, con operazioni come , , , , , . I datastore includono tipicamente running e candidate; il candidate abilita un meccanismo “prepare-and-commit” con atomicità.
  • RESTCONF mappa le risorse modellate con YANG a un’interfaccia RESTful su HTTP(S), usando JSON o XML con media type standardizzati. I metodi si mappano alla semantica di NETCONF (PATCH/PUT per le modifiche).
  • Modalità di fallimento e progettazione:
    • Contesa sui lock: Coordinare l’uso di per evitare deadlock; usare uno scope ristretto e timeout.
    • Fallimenti parziali: Preferire il datastore candidate + per modifiche transazionali. Se è disponibile solo il datastore running, usare gruppi di modifiche strutturati e checkpoint.
    • Model drift: I dispositivi possono supportare diverse revisioni dei moduli YANG; negoziare le capacità e testare durante la CI.
• Esempi concisi:
  • Aggiornamento parziale con RESTCONF (scambio 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()

Strumenti e Flussi di Lavoro: Python, Ansible, Git e Pipeline

• Automazione con Cisco DNA Center:
  • Le API REST Northbound forniscono accesso a inventario, template, provisioning e funzionalità di assurance. Le interfacce Southbound collegano il controller ai dispositivi (CLI, SNMP, NETCONF/RESTCONF) per attuare l’intent.
  • I workflow di Discovery possono usare CDP, LLDP e intervalli di indirizzi IP. Utilizzare il controllo degli accessi basato sui ruoli, template basati su progetti e variabili per sito. La funzionalità di Assurance correla la telemetria per identificare problemi, punteggi di salute e azioni correttive suggerite: input fondamentali per l’automazione a ciclo chiuso.
• Fondamenti di Python per l’automazione di rete:
  • Linguaggio base: tipi, funzioni, moduli, ambienti virtuali e logging.
  • Librerie: requests/httpx (REST), ncclient (NETCONF), jinja2 (templating), pyyaml, json, pandas (manipolazione dei dati), rich/logging per l’osservabilità.
  • Pratiche: validazione dell’input, tentativi ripetuti con backoff, eccezioni strutturate, timeout e unit test. Serializzare la logica di business separatamente dall’I/O per semplificare i test.
• Ansible:
  • L’inventario (Inventory) definisce host e gruppi; mantenere host_vars/group_vars in formato YAML.
  • I Playbook dichiarano lo stato desiderato; moduli come ios_config, ios_facts, iosxe_config, restconf_config e uri eseguono le azioni. Usare i ruoli (roles) per incapsulare logica riutilizzabile.
  • Idempotenza: i moduli assicurano che esecuzioni ripetute convergano senza causare modifiche indesiderate. Usare check_mode e diff per visualizzare un’anteprima; notificare gli handler per salvare solo in caso di modifiche.
  • Esempio:
    • 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
  • Controllo delle modifiche: usare finestre di manutenzione, una strategia seriale (serial) o a lotti (batched) e throttling per sito per limitare il raggio d’impatto (blast radius). Acquisire automaticamente i controlli pre e post-modifica.
• Git, versioning, test e pipeline:
  • Archiviare l’intent di rete (variabili YAML, template Jinja, playbook), le configurazioni generate e i test in Git. Usare branch, pull request e code review. Commit semantici e tag allineano le versioni con le implementazioni.
  • Test: eseguire il lint di file YAML e playbook, validare schemi YANG/JSON, eseguire unit test e test di scenario con Ansible Molecule. Integrare pre-check sintetici (ad esempio, la raggiungibilità) nella CI.
  • Pipeline: Sviluppo (Dev) → staging/lab → canary in produzione → rollout graduale. I gate includono analisi statica, dry-run su simulatori, approvazioni e rollback automatico in caso di regressione dello stato di salute (health).

Telemetria, automazione basata su eventi e gestione del rischio

• Streaming di telemetria:
  • La telemetria model-driven (IOS XE, NX-OS) pubblica lo stato modellato in YANG a intervalli definiti tramite gRPC/gNMI o NETCONF, con sottoscrizioni dial-in o dial-out. I vantaggi includono bassa latenza e dati strutturati, superando le prestazioni dello scraping periodico della CLI o del polling SNMP.
  • Esempio (IOS XE, conciso):

undefined

• Suggerimenti di progettazione: allineare la frequenza di campionamento al caso d’uso; garantire la capacità del message bus; progettare pipeline di downsampling/aggregazione; proteggere dalla perdita di telemetria con buffering e acknowledgment.
• Automazione basata su eventi:
  • Attivare azioni su webhook, syslog, trap SNMP, eventi di DNA Center o topic Kafka. Utilizzare la correlazione e il rate limiting per evitare flap indotti da storm di eventi. Mantenere handler idempotenti che possano essere rieseguiti in sicurezza.
  • A ciclo chiuso (closed-loop): un controller rileva una violazione della policy, la convalida con segnali secondari, apre un ticket di modifica o avvia una remediation limitata, quindi riesegue la misurazione e finalizza.
• Gestione del rischio, rollback e credenziali:
  • Misure di protezione (Guardrails): rollout graduali (staged), limiti di concorrenza, controlli del raggio d’impatto (blast-radius), backoff dinamico su risposte 429/5xx e timeout. Utilizzare transazioni dove disponibili (NETCONF candidate + commit), oppure checkpoint del dispositivo e configure replace.
  • Rollback: mantenere configurazioni di riferimento (golden config), diff e checkpoint per dispositivo. Preferire la semantica commit-confirmed dove supportata; altrimenti, implementare un fallback automatizzato tramite timer e controlli di raggiungibilità.
  • Protezione delle credenziali: imporre RBAC, token a breve durata e segreti just-in-time per ogni job. Utilizzare archivi di segreti (ad esempio, Ansible Vault o un vault esterno), non incorporare mai i segreti nei playbook o in Git. Ruotare le credenziali secondo una pianificazione e dopo cambiamenti di personale. Proteggere le credenziali tra controller e dispositivo e verificare gli accessi (audit).

Scenario pratico

Aurelius Logistics pianifica di standardizzare le configurazioni di campus e filiali, imporre una segmentazione coerente e implementare un’assurance a ciclo chiuso utilizzando Cisco DNA Center, abilitando al contempo modifiche sicure tramite Ansible e Git.

1. Effettuare il baselining e la discovery della rete

• Motivazione: La discovery di DNA Center tramite intervalli IP e CDP/LLDP enumera dispositivi e topologia, stabilendo un inventario autorevole. Ciò consente di definire lo scope dell’intento e l’ereditarietà delle variabili per sito. La raccolta dei dati di assurance stabilisce baseline di stato pre-modifica per il confronto e per l’attivazione dei rollback.

2. Modellare l’intento e i template in DNA Center

• Motivazione: Esprimere in modo dichiarativo la segmentazione (ad esempio, dipendenti, IoT, ospiti) e le policy QoS. Utilizzare template parametrizzati con variabili di sito per interfacce, routing e ACL. La policy dichiarativa consente al controller di compilare configurazioni specifiche per dispositivo, riducendo l’errore umano e il drift.

3. Implementare la gestione della configurazione guidata da Git

• Motivazione: Archiviare template, variabili di sito (YAML) e test di validazione in Git. I feature branch e le pull request impongono la revisione paritaria (peer review). I tag allineano i deployment alle versioni, consentendo un rollback preciso. Ciò fornisce una cronologia delle modifiche verificabile e supporta l’attivazione automatica di pipeline.

4. Costruire una pipeline CI/CD con gate di validazione

• Motivazione: Le fasi della pipeline eseguono il linting di YAML, validano i payload JSON/YANG, effettuano unit test del rendering Jinja e simulano chiamate API in una sandbox. I dry run di DNA Center e le modalità check_mode/diff di Ansible validano le modifiche senza alcun impatto. Solo dopo aver superato tutti i gate, la pipeline consente all’operatore di approvare e procedere.

5. Eseguire il deploy incrementale con Ansible e le API di DNA Center

• Motivazione: Utilizzare le API northbound di DNA Center per inviare i template prima a un sito canary, quindi effettuare il rollout in serie per sito con limiti sulla dimensione dei batch. Per i dispositivi che supportano NETCONF/RESTCONF, i moduli Ansible eseguono aggiornamenti mirati e idempotenti. Questo duplice approccio sfrutta il controller per le attività ad alta intensità di policy e l’automazione diretta dei dispositivi per modifiche granulari, riducendo al minimo il raggio d’impatto.

6. Attivare la telemetria in streaming e i controlli guidati dall’assurance

• Motivazione: Configurare la telemetria model-driven sui dispositivi perimetrali per alimentare DNA Center Assurance e lo stack di osservabilità aziendale. Definire SLO (ad esempio, tasso di successo dell’onboarding, latenza) e sottoscrizioni a eventi che generano allarmi se le metriche post-modifica peggiorano. Ciò consente il rilevamento immediato di esiti negativi.

7. Abilitare la remediation a ciclo chiuso controllata

• Motivazione: Per deviazioni ben comprese (ad esempio, interfaccia inattiva con un workaround noto), consentire alla pipeline di attivare un playbook vincolato per annullare l’ultima modifica o applicare un hotfix. Richiedere l’approvazione umana per remediation più ampie. Implementare un backoff esponenziale e un cooldown per prevenire oscillazioni.

8. Preparare e testare i percorsi di rollback

• Motivazione: Prima di ogni modifica, creare checkpoint del dispositivo o usare NETCONF candidate + commit-confirmed se disponibile. Archiviare le configurazioni pre-modifica e taggare la repository Git. Se gli health score diminuiscono o la telemetria mostra violazioni degli SLA, la pipeline esegue configure replace o NETCONF discard/rollback, ripristinando rapidamente lo stato precedente.

9. Proteggere le credenziali e imporre il controllo degli accessi

• Motivazione: Archiviare le credenziali di dispositivi/controller in un vault; iniettare token a breve durata nei job. Utilizzare l’RBAC di DNA Center per limitare gli scope delle API. Non registrare mai i segreti nei log; ripulire gli output nella CI. Ruotare regolarmente credenziali e token e dopo cambiamenti di personale per ridurre i rischi.

10. Operazionalizzare con documentazione e runbook

• Motivazione: Documentare le definizioni dell’intento, gli schemi delle variabili, le modalità di guasto (rate limit, errori API, discrepanze del modello) e i passaggi di ripristino. Formare il NOC per interpretare i segnali di assurance e gli stati della pipeline, garantendo risposte coerenti e rapide agli incidenti.

Questo approccio crea un percorso sicuro e testabile dall’intento all’implementazione, sfrutta i controller per la distribuzione delle policy (con vManage/vSmart in SD-WAN e DNA Center nel campus), utilizza strumenti idempotenti per la convergenza e chiude il cerchio con una validazione supportata dalla telemetria e una remediation controllata.

← Sicurezza Enterprise e Servizi di Identità · Tutti i domini · Network Assurance →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →