L’automazione sta cambiando il modo in cui gestiamo le reti. Nel modello tradizionale, ogni switch e router viene configurato singolarmente via CLI (SSH o console), device-by-device. Questo approccio è preciso ma lento, ripetitivo e soggetto a errori umani: un typo su una ACL o una VLAN mancante su un uplink può propagarsi silenziosamente. Le reti controller-based spostano l’intelligenza di configurazione e policy su un controller centrale, che programma i device in modo coerente e a scala.

Networking tradizionale vs controller-based

In una rete tradizionale ogni dispositivo è autonomo: prende decisioni di forwarding basandosi sulle proprie tabelle (routing table, MAC address table, STP) costruite dai protocolli distribuiti (OSPF, EIGRP, BGP, STP). Non esiste una vista d’insieme: il “cervello” è distribuito su decine di scatole.

In una rete controller-based, un controller (in Cisco, DNA Center per il campus, con Catalyst 9000) mantiene la vista globale della topologia, calcola le policy e le spinge sui device. L’operatore lavora sull’intent (“questi utenti possono raggiungere questo gruppo di server”) e il controller traduce l’intento in configurazione concreta.

Aspetto Tradizionale (device-by-device) Controller-based (DNA Center)
Punto di gestione Ogni device via CLI Controller centralizzato (GUI/API)
Consistenza A carico dell’operatore Garantita dal controller
Scala Lineare con lo sforzo umano Automatizzata
Troubleshooting Hop-by-hop Assurance centralizzata

Control plane e data plane

Ogni dispositivo di rete svolge due funzioni logiche:

  • Control plane: decide come instradare il traffico. Costruisce le tabelle (adiacenze OSPF, best path BGP, calcolo STP, popolamento della MAC table).
  • Data plane (forwarding plane): inoltra effettivamente i pacchetti secondo quanto deciso dal control plane, tipicamente in hardware (ASIC).

Nelle architetture software-defined il control plane viene (in tutto o in parte) centralizzato sul controller, mentre il data plane resta sui device fisici. Il controller diventa così il punto in cui risiede la logica decisionale della rete. Attenzione: in un modello puramente SDN il controller ospita il control plane; nel modello Cisco DNA “controller-based” i device mantengono un proprio control plane (es. LISP nel fabric), ma policy e automazione sono centralizzate.

Underlay, overlay e fabric

Una fabric SDN si costruisce su due livelli logici:

  • Underlay: la rete fisica di trasporto (switch, router, cablaggio) con un IGP semplice (spesso IS-IS o OSPF) il cui unico scopo è garantire raggiungibilità IP tra i nodi. Deve essere stabile e “invisibile”.
  • Overlay: una rete virtuale costruita sopra l’underlay tramite tunnel di incapsulamento (in SD-Access: VXLAN per il data plane, LISP per il control plane, CTS/SGT per la policy). L’overlay trasporta il traffico utente indipendentemente dalla topologia fisica sottostante.

La fabric è l’insieme di underlay + overlay che opera come un unico sistema programmabile.

API northbound e southbound

Il controller comunica in due direzioni, ed è il punto più insidioso dell’esame:

  • Northbound API (NBI): guardano verso l’alto, verso le applicazioni, gli script e i tool di orchestrazione. Sono tipicamente REST API (JSON/HTTPS). Un’app di business o uno script Python (DevNet) usa la NBI per chiedere alla rete cosa fare, senza sapere come è fatta.
  • Southbound API (SBI): guardano verso il basso, verso i device. Sono i protocolli con cui il controller programma switch e router: NETCONF/YANG, RESTCONF, SNMP, CLI.
Applicazioni / script (DevNet)
        ▲  Northbound API (REST)
   [ Controller: DNA Center ]
        ▼  Southbound API (NETCONF, RESTCONF, SNMP)
   Switch / Router (data plane)

Cisco DNA Center offre inoltre Assurance (telemetria e analisi proattiva della salute della rete), automazione dei workflow e integrazione con Cisco ISE per l’identità e le policy basate su SGT. La sua NBI REST consente di integrare la rete con strumenti esterni e pipeline di automazione.

Trappole tipiche d’esame

  • Scenario: “un’applicazione deve programmare la rete tramite il controller — quale API?” → Northbound API (REST). Northbound = verso le applicazioni.
  • Scenario: “il controller deve inviare la configurazione ai device — quale interfaccia?” → Southbound API (NETCONF/RESTCONF/SNMP). Southbound = verso i device.
  • Scenario: “in un’architettura software-defined dove risiede la logica decisionale?” → Il control plane è centralizzato sul controller; il data plane resta sui device.
  • Scenario: “quale componente fornisce solo raggiungibilità IP di trasporto per la fabric?” → L’underlay; l’overlay (VXLAN/LISP) trasporta il traffico utente.
  • Scenario: “device-by-device vs centralizzato, quale riduce errori di configurazione a scala?” → L’approccio controller-based (DNA Center), che garantisce consistenza.