Cisco 200-301: WAN, Automazione, Virtualizzazione e Operazioni di Rete — Guida allo studio

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Fa parte della Cisco CCNA 200-301 — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Virtualizzazione, Overlay/Underlay e SD-WAN

La virtualizzazione di rete separa le reti logiche dal trasporto fisico per fornire segmentazione, multi-tenancy e inoltro flessibile.

• VRF (VRF-Lite senza MPLS, o con MPLS nei core dei provider): Tabelle di routing multiple su un singolo dispositivo. Ogni VRF isola interfacce, rotte e policy. Evitare i “route leak” (perdite di rotte) utilizzando policy esplicite di route-target nelle implementazioni MPLS o filtri statici/di confine in VRF-Lite.

Esempio—semplice VRF-Lite:

undefined

• Underlay e overlay a confronto: L’underlay fornisce la raggiungibilità IP tra i nodi (es. ISP, MetroE, MPLS). Gli overlay (GRE, IPsec, VXLAN, fabric SD-WAN) trasportano il traffico dei tenant o segmentato. Operare su ogni livello in modo indipendente per semplificare il troubleshooting: testare prima l’underlay (ping tra gli endpoint del tunnel), poi l’overlay (ping attraverso il tunnel).

L’SD-WAN arricchisce gli overlay con controllo e policy centralizzati:

• Componenti: I router di edge formano tunnel crittografati nel data-plane; i controller includono un orchestrator (onboarding/attraversamento NAT), un control-plane (scambio di rotte e policy di sicurezza) e un piano di gestione (GUI/API, template, monitoraggio). I certificati stabiliscono la fiducia reciproca (mutual trust) e il zero-touch provisioning.
• Inoltro basato su policy (Policy-driven forwarding): Il routing “application-aware” indirizza i flussi in base a metriche SLA (perdita, latenza, jitter), DSCP e intenti di business. Le policy sui dati (service chaining, NAT), le policy di controllo (advertisement/accettazione delle rotte) e le policy di sicurezza (FW/IDS) vengono applicate in modo coerente.

Ragionamenti di progettazione e compromessi (trade-off):

• Trasporti doppi o multipli (MPLS, Internet, LTE) migliorano la disponibilità e l’efficienza dei costi; i controller sondano continuamente i percorsi e selezionano i link migliori per ogni applicazione. Compromesso: maggiore complessità nella progettazione delle policy e nel monitoraggio.
• Il controllo centralizzato riduce gli errori di configurazione ma è sensibile alla raggiungibilità del controller e al ciclo di vita dei certificati. Distribuire la ridondanza dei controller su siti diversi e monitorare le connessioni di controllo.
• Il routing asimmetrico può verificarsi quando le applicazioni vengono indirizzate in modo diverso per direzione; assicurarsi che il traffico di ritorno rispetti i dispositivi stateful o utilizzare policy simmetriche.

Modalità di guasto comuni in SD-WAN:

• Disallineamenti di certificati/orologio (clock skew) impediscono le connessioni di controllo. Applicare NTP e monitorare la scadenza dei certificati.
• Problemi di attraversamento NAT (NAT traversal) dietro firewall restrittivi. Verificare le porte UDP/TCP richieste e i meccanismi di fallback.
• Sequenze di policy in ordine errato possono scartare inavvertitamente prefissi o classificare app in modo non corretto. Testare in ambiente di staging e applicare contatori (hit-counter) e logging per confermare le corrispondenze.

Automazione, Cisco DNA Center e Programmabilità

L’Intent-Based Networking (IBN) codifica i risultati desiderati in policy e ne automatizza l’applicazione con validazione.

Concetti di Cisco DNA Center (DNAC):

• Inventory e topologia: Rileva i dispositivi tramite SNMP/CLI/API, costruisce la topologia e mantiene gli attributi hardware/software.
• Automazione: Provisioning basato su template, gestione delle immagini, onboarding dei dispositivi (Plug and Play) e workflow di accesso software-defined.
• Assurance: Punteggi di salute (health score) basati sulla telemetria per client, dispositivi e applicazioni; le baseline e il rilevamento delle anomalie accelerano l’analisi delle cause radice (root-cause analysis).
• Policy: Traduce l’intento (segmentazione, QoS, controllo degli accessi) in configurazioni distribuibili con controlli di conformità (compliance check).

API REST e codifica dei dati:

• Metodi HTTP: GET (recupera), POST (crea), PUT/PATCH (sostituisci/modifica), DELETE (rimuovi). GET è idempotente; prestare attenzione all’idempotenza per i tentativi ripetuti (retry).
• Formati dei dati: JSON è lo standard de facto; YAML/TOML possono apparire negli strumenti di tooling, ma le API REST scambiano tipicamente JSON. Usare UTF-8 e gli header Content-Type/Accept appropriati.
• Autenticazione: L’autenticazione Basic è semplice ma insicura senza TLS; è preferibile l’autenticazione basata su token (chiavi API o JWT); OAuth 2.0 fornisce autorizzazione delegata. Usare sempre TLS, validare i certificati e gestire il rinnovo dei token.
• Codici di stato: 200/201 per successo, 202 per operazioni asincrone, 400/404 per errori del client, 401/403 per fallimenti di autenticazione/autorizzazione, 429 per superamento dei limiti di richieste (rate limit), 5xx per errori del server. Progettare un meccanismo di backoff per i codici 429/5xx.

Esempio—payload JSON per una variabile di template di interfaccia:

undefined

Gestione della configurazione e automazione dell’infrastruttura:

• Controllo di versione: Archiviare configurazioni, template e playbook in Git. Usare branch e pull request per le revisioni e per mantenere una traccia di controllo (audit trail).
• Idempotenza: Gli strumenti applicano lo stato desiderato senza apportare modifiche ripetute; ciò migliora la prevedibilità e la conformità.
• Inventory e templating: Strutturare gli inventory di host/gruppi e parametrizzare le configurazioni con Jinja2. Mantenere configurazioni “golden” e controlli di conformità.
• Gestione dei segreti (Secrets management): Proteggere credenziali e chiavi usando vault o astrazioni a livello di ambiente; evitare il testo in chiaro nei repository.
• CI/CD per la rete: Eseguire il “linting” delle configurazioni, simulare le policy, eseguire unit test sui template e implementare i deployment in staging con controlli pre e post-distribuzione (pre-check/post-check).

Casi d’uso di Ansible e Python:

• Ansible: Modifiche rapide su più dispositivi, aggiornamenti di immagini, provisioning di interfacce/VRF e controlli di conformità tramite i moduli di rete. Estratto di un playbook di esempio:

undefined

• Python: Scripting ad hoc, integrazioni API e validazioni personalizzate. Usare requests per le chiamate REST o librerie specifiche per la CLI di rete. Concetto di esempio:

undefined

Operatività, Affidabilità e Risoluzione dei Problemi

Una gestione operativa rigorosa riduce i rischi e migliora l’uptime.

Controllo delle modifiche:

• Definire ambito, rischio, rollback, test di validazione e tempistiche. Richiedere revisione paritaria (peer review) e deployment graduale (laboratorio → pilota → rollout per fasi).
• Le finestre di manutenzione e le notifiche ai clienti definiscono le aspettative. Utilizzare una procedura operativa (“method of procedure”) con checkpoint espliciti.

Backup e gestione delle immagini:

• Backup notturni di running-config, startup-config e dei database critici dei controller. Convalidare i backup con ripristini periodici in un ambiente di laboratorio.
• Immagini “golden” e cataloghi di immagini allineati ai requisiti hardware e di funzionalità. Precaricare le immagini durante i periodi di bassa attività; considerare l’ISSU dove supportato per minimizzare il downtime.
• Verificare i checksum MD5/SHA e le firme; tenere traccia delle note di rilascio (release notes) e degli avvisi tecnici (field notices).

Disaster recovery:

• Gestione out-of-band e accesso alla console per dispositivi bloccati (“bricked”).
• Controller ridondanti e storage di backup off-site. Documentare e testare periodicamente i runbook di ripristino.
• Per SD‑WAN e DNAC, esportare chiavi/certificati e mantenere procedure per il re-deployment dei controller.

Risoluzione sistematica dei problemi:

• Definire il problema e il suo impatto; riprodurlo se possibile.
• Stabilire una baseline: confrontare i valori attuali di CPU, memoria, contatori delle interfacce, record di flusso e latenza con i dati storici. Le modifiche rispetto all’ultimo stato funzionante noto sono i principali sospetti.
• Isolare per livelli OSI e per underlay vs overlay. Validare prima il livello fisico/link, poi la raggiungibilità IP, poi il control plane (routing/OMP), poi il data plane (ACL/NAT/QoS) e infine l’applicazione.
• Formulare ipotesi, testarle con modifiche minime e strumentare con catture mirate, debug o telemetria. Evitare modifiche indiscriminate.

Analisi della causa radice (Root-Cause Analysis):

• Documentare la timeline, la catena causale e i fattori contribuenti. Distinguere il trigger dal difetto sottostante (es. la scadenza di un certificato ha causato la perdita di controllo perché mancavano le soglie di monitoraggio).
• Implementare azioni correttive e preventive: monitoraggio, aggiornamento dei runbook, standard di configurazione e formazione.

Errori operativi comuni:

• Derive (drift) dalle configurazioni “golden” nel tempo; risolvere con scansioni di conformità e auto-remediation.
• Sovrapposizioni di policy non coordinate in SD‑WAN o ACL che causano scarti di pacchetti involontari; risolvere con “linting” centralizzato delle policy e revisione dei contatori di hit (hit-counter).
• Monitoraggio inefficace di latenza/jitter per le applicazioni critiche; risolvere con probe attive e SLO collegati a sistemi di allarme.

Scenario Pratico

BluePeak Manufacturing sta sostituendo la costosa connettività MPLS con una doppia connessione Internet e backup LTE in 40 filiali, introducendo al contempo la segmentazione basata su VRF e l’automazione centralizzata.

1. Costruire l’underlay e validare la raggiungibilità.

• Logica: Un overlay affidabile richiede una connettività IP stabile tra i WAN edge. Ordinare due ISP per ogni filiale, collegarli a porte WAN separate del router e configurare l’LTE come connessione terziaria. Validare con ping e traceroute tra gli IP pubblici, confermare i comportamenti del NAT e assicurarsi che l’ICMP non sia filtrato per supportare PMTUD.

2. Implementare i controller SD‑WAN e registrare gli edge.

• Logica: Il controllo centralizzato abilita policy “intent-driven”. Distribuire nodi ridondanti di orchestrazione, controllo e gestione; integrare la PKI aziendale o usare i certificati integrati. Utilizzare il zero-touch provisioning per l’onboarding sicuro degli edge dietro NAT, verificando la sincronizzazione dell’ora per prevenire errori dei certificati.

3. Definire le VRF e segmentare il traffico.

• Logica: Isolare le reti di produzione, ospiti (guest) e OT. Creare le VRF sui gateway delle filiali e del campus, associare le interfacce appropriate e consentire il passaggio (“leak”) solo dei servizi necessari tramite redistribuzione controllata. Esempio nelle filiali:

undefined

undefined

undefined

undefined

undefined

undefined

4. Creare policy “application-aware” e probe SLA.

• Logica: Indirizzare le applicazioni critiche sul percorso migliore. Configurare probe di perdita/latenza/jitter per ogni trasporto e definire le policy: inviare il traffico ERP sul circuito Internet a più bassa latenza con failover su una VPN equivalente a MPLS se le soglie vengono superate; forzare la VRF guest solo sulla banda larga più economica. Abilitare il ritorno simmetrico dove esistono servizi stateful.

5. Gestire MTU e frammentazione per gli overlay.

• Logica: Prevenire “black hole” dovuti all’overhead di GRE/IPsec. Impostare ip mtu e TCP MSS adjust sui tunnel dove necessario, confermare il PMTUD con ping che utilizzano il DF-bit e assicurarsi che i firewall degli ISP permettano i messaggi ICMP di tipo 3 codice 4.

6. Automatizzare il provisioning di base con Ansible e template.

• Logica: Garantire coerenza e velocità. Archiviare l’inventario dei dispositivi e le variabili in Git, creare template Jinja2 per VRF, interfacce e QoS, e applicarli con playbook idempotenti. Eseguire un pre-controllo delle immagini disponibili e una post-validazione delle adiacenze di routing e degli hit delle policy.

7. Integrare Cisco DNA Center per l’assurance e la gestione delle immagini.

• Logica: Il monitoraggio continuo dello stato di salute e il software standardizzato riducono gli incidenti. Importare i dispositivi nell’inventario, abilitare la telemetria, impostare le immagini “golden” per piattaforma, pianificare aggiornamenti graduali e rimediare automaticamente alle derive (drift) dalle configurazioni “golden”.

8. Mettere in sicurezza e monitorare con le API.

• Logica: L’accesso programmatico scala le operazioni. Usare l’autenticazione basata su token per interrogare lo stato di salute dei dispositivi, lo stato delle policy e gli SLA. Implementare un meccanismo di backoff per le risposte 429 e generare allarmi sulla scadenza dei certificati dei controller e sugli eventi di down del control plane.

9. Eseguire il controllo delle modifiche e il cutover per fasi.

• Logica: Minimizzare il rischio. Avviare un progetto pilota su tre filiali, monitorare le prestazioni delle applicazioni e la corrispondenza con le policy, quindi procedere con il rollout in ondate successive, prevedendo piani di rollback verso MPLS. Mantenere l’accesso out-of-band durante il cutover.

10. Validare, documentare ed eseguire una RCA (Root-Cause Analysis).

• Logica: Confermare il successo e apprendere dall’esperienza. Confrontare latenza/jitter post-cutover con le baseline, esaminare gli errori e le perdite sulle interfacce e raccogliere metriche sull’esperienza utente. Per ogni deviazione, tracciare prima l’underlay, poi i percorsi dell’overlay, aggiustare le policy e documentare i risultati per affinare i template e i runbook.

Questo approccio fornisce una connettività WAN resiliente ed economica, con segmentazione e policy deterministiche, mentre i sistemi di automazione e assurance migliorano la qualità operativa e riducono il tempo di rilevamento (time-to-detect) e il tempo di riparazione (time-to-repair).

← Sicurezza di Rete e Controllo degli Accessi · Tutti i domini

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