Perché serve la gestione programmabile

Nelle reti enterprise moderne, configurare device uno a uno via CLI non scala. Cisco DNA Center (oggi Catalyst Center) è il controller intent-based che centralizza il ciclo di vita della rete campus: l’amministratore esprime l’intento (una policy, una VLAN, una configurazione QoS) e il controller lo traduce in configurazione concreta sui device IOS-XE, usando sotto il cofano protocolli come NETCONF e la telemetria streaming.

I workflow di Cisco DNA Center

La GUI si articola in quattro macro-aree che rappresentano il flusso operativo:

Workflow Scopo
Design Gerarchia dei siti, impostazioni globali (DNS, NTP, AAA, IP pool), template di configurazione
Policy Definizione di gruppi (SGT), access control e macro/micro-segmentazione per SD-Access
Provision Push della configurazione ai device, assegnazione ai siti, onboarding fabric
Assurance Monitoring proattivo, health score, telemetria e troubleshooting

Assurance è il cuore del valore aggiunto: raccoglie telemetria in streaming (non il classico polling SNMP) e la correla con machine learning per produrre health score su rete, client e applicazioni. Strumenti come Path Trace ricostruiscono il percorso hop-by-hop di un flusso, mentre i sensor test e la baseline storica permettono di individuare anomalie prima che l’utente apra un ticket.

A nord, DNA Center espone le Intent API (REST/JSON): un’app esterna chiede cosa vuole ottenere e il controller decide come realizzarlo. A sud, verso i device, usa prevalentemente NETCONF, CLI e SNMP.

NETCONF

NETCONF (RFC 6241) è un protocollo di gestione basato su RPC (Remote Procedure Call) incapsulati in XML. Caratteristiche chiave da ricordare:

  • Transport: SSH sulla porta TCP 830 (default dedicata, non la 22).
  • Encoding: solo XML.
  • Usa i modelli dati YANG per descrivere la struttura della configurazione.
  • Introduce il concetto di datastore: running (config attiva), candidate (area di staging modificabile senza impatto immediato) e startup.

Il flusso tipico è: <edit-config> verso il datastore candidate, eventuale <validate>, poi <commit> per applicare atomicamente le modifiche al running. Se qualcosa non torna, si scarta il candidate senza aver toccato la produzione. Altre operazioni fondamentali sono <get>, <get-config>, <lock>/<unlock> (per evitare modifiche concorrenti) e <copy-config>.

Su IOS-XE l’abilitazione è concettualmente semplice:

Device(config)# netconf-yang

RESTCONF

RESTCONF (RFC 8040) espone gli stessi modelli YANG ma tramite un’interfaccia REST familiare agli sviluppatori web:

  • Transport: HTTPS (HTTP con TLS), tipicamente sulla porta 443.
  • Encoding: JSON oppure XML (negoziato via header Content-Type/Accept, es. application/yang-data+json).
  • Nessun concetto di datastore candidate/commit: si opera direttamente sulle risorse.
  • Usa i verbi HTTP standard mappati sulle operazioni CRUD:
Verbo Azione
GET Legge configurazione o stato operativo
POST Crea una nuova risorsa
PUT Crea o sostituisce integralmente una risorsa
PATCH Modifica parziale (merge)
DELETE Rimuove una risorsa

L’entry point è la radice /restconf/data/..., dove il path riflette la gerarchia del modello YANG. Abilitazione su IOS-XE:

Device(config)# restconf
Device(config)# ip http secure-server

Il quadro d’insieme

NETCONF e RESTCONF non sono in competizione: entrambi si appoggiano a YANG e coesistono sullo stesso device. NETCONF è più ricco (transazioni, lock, candidate, rollback) ed è preferito per automazioni robuste e per il southbound dei controller; RESTCONF è più leggero e immediato per integrazioni web, script e webhook, grazie a JSON e ai verbi REST.

Trappole tipiche d’esame

  • Scenario: “quale porta usa NETCONF?” → TCP 830 (SSH dedicato), non la 22 e non HTTPS. RESTCONF invece viaggia su HTTPS/443.
  • Scenario: domanda che chiede l’encoding. → NETCONF supporta solo XML; RESTCONF supporta sia JSON che XML. Se la risposta dice “NETCONF con JSON”, è sbagliata.
  • Scenario: serve modificare la config in staging e applicarla in modo atomico con possibilità di rollback. → NETCONF con datastore candidate + <commit>. RESTCONF non ha datastore candidate.
  • Scenario: “quale verbo REST sostituisce integralmente una risorsa?” → PUT (replace); PATCH fa merge parziale, POST crea. Attenzione a non confondere PUT e PATCH.
  • Scenario: monitoring proattivo con health score e telemetria in streaming. → è il workflow Assurance di DNA Center, basato su streaming telemetry, non su polling SNMP.
  • Scenario: entrambi i protocolli usano un modello dati comune. → sì, YANG è il denominatore comune di NETCONF e RESTCONF; RESTGET/edit riflettono la struttura YANG nel path/URI.