Perché l’automazione entra nel design ENSLD

Nel progettare una rete enterprise moderna non si sceglie solo topologia, routing e ridondanza: si decide come la rete verrà configurata e osservata nel tempo. L’automazione model-driven sostituisce la CLI manuale e l’SNMP polling con un approccio basato su modelli dati strutturati, protocolli standard e telemetria in streaming. Il progettista deve saper motivare quale meccanismo usare per quale caso d’uso (configurazione vs monitoraggio) e dove collocare l’intelligenza (device diretto vs controller).

YANG: il modello dati come fondamento

YANG è il linguaggio di modellazione (RFC 6020/7950) che descrive in modo gerarchico la struttura di configurazione e stato di un device: container, list, leaf, tipi e vincoli. Non è un protocollo di trasporto: definisce lo schema, che i protocolli poi trasportano.

Esistono tre famiglie di modelli:

Tipo di modello Origine Uso tipico
Native Cisco (IOS-XE, IOS-XR) Accesso completo a feature proprietarie
OpenConfig Vendor-neutral Portabilità multi-vendor
IETF Standard (es. ietf-interfaces) Baseline interoperabile

In un design multi-vendor o cloud-managed, i modelli OpenConfig/IETF riducono il lock-in; per sfruttare feature specifiche IOS-XE si ricorre ai native model.

NETCONF vs RESTCONF

Entrambi i protocolli trasportano dati modellati in YANG, ma con logiche diverse.

NETCONF (RFC 6241) opera su SSH (porta 830), usa encoding XML ed è basato su RPC. Il suo punto di forza è il concetto di datastore: candidate, running, startup. Consente un modello transazionale con commit, confirmed commit e rollback, e permette di applicare in modo atomico un blocco di configurazione. È la scelta corretta quando servono transazioni affidabili, validazione e rollback, specialmente su cambi complessi o multi-device.

RESTCONF (RFC 8040) opera su HTTPS, è basato su REST con verbi HTTP (GET, POST, PUT, PATCH, DELETE) ed encoding JSON o XML. È stateless, più semplice da integrare con tool web/DevOps, ideale per modifiche mirate a singole risorse e per pipeline CI/CD. Non offre lo stesso modello di candidate/commit/rollback di NETCONF.

GET https://device/restconf/data/ietf-interfaces:interfaces

Criterio di design: transazioni robuste e batch → NETCONF; integrazione REST leggera e granulare → RESTCONF.

Model-Driven Telemetry per l’assurance

Il monitoraggio non va risolto con SNMP polling: è pull, poco scalabile e a bassa risoluzione temporale. La Model-Driven Telemetry (MDT) adotta un modello push: il device invia i dati (sempre descritti da YANG) tramite subscription, con cadenza periodic o on-change, verso un collector.

  • Dial-in: il collector apre la sessione e sottoscrive (tipicamente via gNMI/gRPC).
  • Dial-out: il device inizia la connessione verso un collector preconfigurato.

Il trasporto usa gRPC/gNMI con encoding efficiente (GPB/protobuf). Il risultato è telemetria near-real-time ad alta granularità, base indispensabile per l’assurance (analisi trend, anomalie, health). In sede di design, la telemetria è il pilastro del monitoraggio, mentre NETCONF/RESTCONF restano per la configurazione.

Il ruolo dei controller nel design

Configurare device singoli via NETCONF/RESTCONF non scala su centinaia di nodi. I controller introducono un livello di astrazione intent-based ed espongono REST API northbound (JSON/HTTPS):

  • Cisco DNA Center / Catalyst Center: automazione e assurance del campus/branch enterprise (SD-Access). Southbound parla NETCONF e telemetria ai device; northbound offre le Intent API per l’integrazione con sistemi esterni (ITSM, IPAM).
  • Cisco vManage: controller di gestione di SD-WAN, con REST API per orchestrazione di template e policy.

Criterio di design: per operazioni a scala, intent e assurance centralizzata si progetta attorno al controller e alle sue REST API; l’accesso diretto NETCONF/RESTCONF resta per casi puntuali, greenfield o device non gestiti dal controller.

Trappole tipiche d’esame

  • Scenario: serve applicare in modo atomico una config complessa con possibilità di rollback → risposta giusta: NETCONF (datastore candidate + commit/rollback), non RESTCONF.
  • Scenario: monitoraggio scalabile e near-real-time per l’assurance → risposta giusta: model-driven telemetry (push, gNMI), non SNMP polling né GET periodici via RESTCONF.
  • Scenario: “YANG configura direttamente il device?” → no: YANG è il modello dati; il trasporto è NETCONF/RESTCONF/gNMI.
  • Scenario: automazione campus a larga scala con intent e assurance → risposta giusta: Cisco DNA Center via REST API northbound, non scripting NETCONF device-per-device.
  • Scenario: requisito di portabilità multi-vendor → si privilegiano i modelli OpenConfig/IETF rispetto ai native model Cisco.