Data model YANG e API programmabili

La programmabilità di rete introduce un cambio di paradigma: invece di configurare manualmente ogni dispositivo via CLI, un controller o uno script interagisce con l’infrastruttura tramite modelli dati e API strutturate. Capire la separazione tra cosa si descrive (il modello) e come lo si trasporta (il protocollo) è il concetto chiave di questa unità.

YANG: il linguaggio di data modeling

YANG (Yet Another Next Generation) è un linguaggio che descrive in modo formale la struttura dei dati di configurazione e di stato operativo di un dispositivo. Non è un protocollo e non trasporta nulla: definisce solo lo schema, cioè quali dati esistono, di che tipo sono e come sono organizzati gerarchicamente.

Gli elementi costitutivi principali sono:

Esistono due grandi famiglie di modelli: native (specifici Cisco, es. Cisco-IOS-XE-native, che espongono tutto il ricco set di feature del dispositivo) e open/standard (IETF e OpenConfig, es. ietf-interfaces, openconfig-interfaces), che offrono uno schema uniforme multi-vendor a costo di coprire un sottoinsieme di funzioni. La scelta dipende dal trade-off tra portabilità e completezza.

NETCONF e RESTCONF: i protocolli di trasporto

I dati modellati in YANG viaggiano tramite protocolli distinti:

• NETCONF: usa XML su una sessione SSH (porta 830), con operazioni esplicite (<get>, <get-config>, <edit-config>) e il concetto di datastore (running, candidate, startup). Supporta transazioni e commit, adatto a configurazioni complesse e atomiche.
• RESTCONF: espone gli stessi modelli YANG via HTTP/HTTPS (porta 443) con verbi REST (GET, POST, PUT, PATCH, DELETE) e payload in JSON o XML. È più semplice e immediato per script e integrazioni web.

Il punto da fissare: YANG è lo schema, NETCONF/RESTCONF sono il mezzo. Lo stesso modello ietf-interfaces può essere letto sia via NETCONF sia via RESTCONF.

GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
Accept: application/yang-data+json

Le API dei controller Cisco

Al livello di overlay/controller l’astrazione sale ulteriormente, esponendo API REST verso funzioni di rete anziché verso il singolo device:

• Cisco DNA Center (Catalyst Center): API REST Intent-based per l’automazione del fabric enterprise. Il flusso tipico prevede l’autenticazione a /dna/system/api/v1/auth/token per ottenere un token da inserire nell’header X-Auth-Token delle chiamate successive.
• vManage (Cisco SD-WAN): API REST per gestire policy, template e dispositivi dell’overlay. L’autenticazione avviene tramite login basato su sessione/cookie (JSESSIONID) verso /j_security_check.

Interpretare i response code REST

Ogni chiamata REST restituisce un HTTP status code che ne comunica l’esito. Le classi da conoscere:

Distinzione fondamentale: 401 Unauthorized indica autenticazione mancante o non valida (token assente/scaduto → rieffettuare il login), mentre 403 Forbidden indica che l’utente è autenticato ma non autorizzato a quella risorsa (problema di permessi/RBAC, non di credenziali). Il payload di risposta (JSON/XML) contiene i dati richiesti in caso di successo oppure il dettaglio dell’errore, utile per il debugging.

Trappole tipiche d’esame

• Scenario: la domanda chiede “quale protocollo usa modelli YANG” → risposta giusta NETCONF o RESTCONF; YANG è il linguaggio di modeling, non un protocollo di trasporto.
• Scenario: una chiamata API restituisce 401 dopo un’ora di script funzionante → token scaduto/mancante, va rinnovata l’autenticazione. Non confonderlo con 403, che significa autenticato ma privo di permessi.
• Scenario: serve configurare via HTTPS con verbi REST e JSON → RESTCONF (443); se invece si citano datastore candidate/commit su SSH 830 → NETCONF.
• Scenario: si vuole uno schema multi-vendor uniforme → modello OpenConfig/IETF, non il modello native Cisco (che è specifico e più completo ma non portabile).
• Scenario: risposta 204 No Content dopo un PUT/DELETE → è un successo (operazione eseguita senza body), non un errore.