Le nuove certificazioni Cisco CCNA Automation e CCNP Automation

In pratica, invece di entrare su ogni dispositivo per configurarlo manualmente, si definiscono modelli, template e logiche di configurazione che possono essere applicati in modo coerente e ripetibile su centinaia o migliaia di apparati. La CLI non scompare, rimane uno strumento fondamentale per troubleshooting, verifica e interventi mirati ma smette di essere l’unico mezzo attraverso cui si gestisce la rete.

Il vero cambiamento sta quindi nel passare da un approccio operativo e manuale a uno ingegneristico e programmabile, in cui il network engineer inizia a ragionare sempre più in termini di processi, astrazione e automazione, piuttosto che di singoli comandi digitati su un terminale. In altre parole, non si tratta solo di imparare nuovi strumenti: si tratta di ripensare il modo in cui si progetta e si gestisce una rete.

Python per chi viene solo dal networking

Per molti professionisti del networking, l’introduzione di Python rappresenta uno degli aspetti più intimidatori del percorso verso l’automazione. Chi ha costruito la propria carriera lavorando principalmente con protocolli, topologie di rete e configurazioni CLI potrebbe trovarsi improvvisamente di fronte a concetti come variabili, funzioni, cicli e librerie software. È normale, quindi, percepire inizialmente una certa distanza tra il mondo del networking tradizionale e quello della programmazione.

La buona notizia è che Python è stato scelto proprio perché è uno dei linguaggi più accessibili. La sua sintassi è relativamente semplice e leggibile, e permette di ottenere risultati concreti con poche righe. In ambito networking, inoltre, spesso non è necessario sviluppare software complessi: l’obiettivo è generalmente quello di automatizzare attività ripetitive, raccogliere informazioni dai dispositivi o applicare configurazioni in modo consistente su molti apparati.

Molti degli strumenti utilizzati nel networking automation (Netmiko, Nornir, NAPALM o le API REST delle piattaforme di gestione) sono pensati proprio per essere utilizzati da network engineer che stanno muovendo i primi passi nella programmazione. Questo significa che, nella pratica, si tratta spesso di scrivere piccoli script che leggono dati da file, iterano su una lista di dispositivi e applicano determinate operazioni.

Il vero salto non è tanto diventare programmatori professionisti, ma acquisire una mentalità di base da sviluppatore: imparare a leggere il codice, modificarlo, adattarlo al proprio contesto e comprendere la logica che sta dietro a un processo automatizzato. Con il tempo, Python smette di sembrare una barriera e diventa semplicemente un nuovo strumento nella cassetta degli attrezzi del network engineer, uno strumento molto potente.

Uso di Git e controllo versione

Un altro concetto che è presente nel percorso delle certificazioni di Network Automation è l’utilizzo di Git e, più in generale, dei sistemi di controllo versione come Github. Per chi proviene dal networking tradizionale questo può sembrare inizialmente un argomento un po’ fuori contesto.

Per anni le configurazioni di rete sono state salvate su file di testo, repository interni o semplicemente nella memoria degli apparati. Nel mondo dell’automazione, però, il codice e le configurazioni iniziano a essere trattati sempre più come vero e proprio software. Script Python, template di configurazione, file YAML con l’inventario dei dispositivi o modelli YANG diventano tutti elementi fondamentali dell’infrastruttura. A questo punto diventa naturale utilizzare strumenti come Git per tenere traccia delle modifiche, collaborare con altri colleghi e mantenere una storia chiara delle configurazioni.

Il controllo versione permette, ad esempio, di sapere chi ha modificato cosa e quando, di confrontare diverse versioni di un file e, soprattutto, di tornare rapidamente indietro se una modifica introduce problemi. In ambienti complessi questo può fare una differenza enorme, perché consente di gestire l’evoluzione della rete con un livello di controllo molto maggiore rispetto alla semplice modifica manuale delle configurazioni.

Anche in questo caso non è necessario diventare esperti sviluppatori per trarne beneficio. Spesso bastano pochi comandi di base (clone, add, commit e push) per iniziare a integrare Git nel proprio flusso di lavoro.

Concetti DevOps (CI/CD, pipeline)

Avvicinandosi al mondo dell’automazione di rete, è quasi inevitabile imbattersi anche in alcuni concetti tipici della cultura DevOps, come CI/CD e pipeline di automazione. Per chi proviene dal networking tradizionale questi termini possono sembrare inizialmente molto lontani dal proprio lavoro quotidiano, ma in realtà stanno diventando sempre più rilevanti anche nella gestione delle infrastrutture di rete.

Nel contesto DevOps, CI/CD significa Continuous Integration e Continuous Delivery (o Deployment). In ambito software questi processi permettono di integrare modifiche al codice in modo continuo, testarle automaticamente e distribuirle in modo controllato negli ambienti di produzione. Nel networking automation il principio è più o meno simile: le configurazioni, i template e gli script che gestiscono la rete vengono trattati come codice, e possono quindi seguire lo stesso tipo di flusso.

Le pipeline rappresentano proprio la sequenza di passaggi automatizzati che portano una modifica dalla fase di sviluppo fino alla sua applicazione sull’infrastruttura. Per esempio, una pipeline potrebbe verificare automaticamente la sintassi di un template, eseguire alcuni test di validazione su configurazioni generate, simulare il deployment su un ambiente di laboratorio e solo successivamente permettere la distribuzione sugli apparati reali.

Non significa necessariamente che ogni network engineer debba trasformarsi in un esperto di DevOps, ma comprendere questi concetti aiuta a capire come l’automazione si inserisce nei processi moderni di gestione delle infrastrutture. Sempre più spesso, infatti, le reti non sono più gestite come sistemi isolati, ma come parte integrante di piattaforme software più ampie, dove automazione, sviluppo e operatività lavorano insieme.

Comprendere e usare modelli YANG

Un altro concetto che compare spesso nel mondo dell’automazione di rete (che inizialmente può sembrare piuttosto ostico) è quello dei modelli YANG. Per molti network engineer abituati alla configurazione tramite CLI, l’idea di descrivere una configurazione attraverso modelli di dati può apparire come qualcosa di molto distante dalla pratica quotidiana.

In realtà, il concetto non è così alieno come potrebbe sembrare, soprattutto per chi ha già avuto a che fare con SNMP e con le MIB.
Le MIB (Management Information Base) sono infatti dei modelli che descrivono in modo strutturato quali informazioni un dispositivo espone tramite SNMP: ogni parametro è identificato da un OID, contiene un valore di uno specifico tipo (INTEGER, OCTET STRING, IpAddress, Counter32 e così via) ed è organizzato all’interno di una gerarchia ben definita. Quando si interroga un apparato via SNMP, in realtà si stanno leggendo dati che sono stati descritti e organizzati proprio tramite queste MIB.

I modelli YANG funzionano in modo concettualmente molto simile, ma con uno scopo più ampio. Se le MIB descrivono principalmente informazioni di monitoraggio e stato, i modelli YANG descrivono configurazioni, stato operativo e strutture dati complete del dispositivo. In altre parole, YANG definisce come sono organizzati i dati di un dispositivo di rete, un po’ come una MIB definisce gli OID disponibili in SNMP, ma con una struttura più ricca e pensata anche per la configurazione.

Questo approccio è alla base di protocolli moderni come NETCONF e RESTCONF, che permettono di interagire con i dispositivi tramite API. I modelli YANG descrivono quali parametri esistono e come sono organizzati, fungendo di fatto da contratto tra il dispositivo e gli strumenti di automazione.

Per chi viene dal networking tradizionale si tratta soprattutto di cambiare prospettiva: non pensare più alla configurazione come a una sequenza di comandi CLI, ma come a dati strutturati.

La buona nuova è che non serve diventare sviluppatori di modelli YANG: nella maggior parte dei casi è sufficiente saper leggere il modello, capire quali parametri sono disponibili e utilizzarli tramite API o strumenti di automazione.

Terraform ed Ansible

Nel percorso verso l’automazione delle infrastrutture di rete è molto probabile imbattersi anche in strumenti come Terraform ed Ansible, due tecnologie molto diffuse nel mondo DevOps e sempre più presenti anche nel networking.

Ansible è probabilmente lo strumento più familiare per chi proviene dal networking. Si tratta di una piattaforma di automazione che permette di eseguire configurazioni e operazioni su molti dispositivi contemporaneamente utilizzando semplici file di testo chiamati playbook, scritti in YAML. In pratica è possibile definire una serie di operazioni,  ad esempio configurazioni, verifiche o raccolta di informazioni, e farle eseguire automaticamente su un’intera infrastruttura.

Terraform, invece, appartiene a una categoria leggermente diversa: è uno strumento pensato per gestire infrastrutture attraverso il paradigma Infrastructure as Code (IaC). In questo caso non si tratta tanto di eseguire comandi sui dispositivi, ma di descrivere lo stato desiderato di un’infrastruttura in un file di configurazione. Terraform si occupa poi di creare, modificare o eliminare le risorse necessarie per raggiungere quello stato.
Questo approccio è molto diffuso negli ambienti cloud, ma sta trovando applicazione anche nel networking, ad esempio per gestire reti virtuali, infrastrutture di data center o piattaforme di orchestrazione.

Come per molti degli strumenti citati nel percorso Automation, la difficoltà iniziale è soprattutto legata al cambio di approccio: si passa dal configurare manualmente i dispositivi a descrivere come deve essere l’infrastruttura, lasciando poi che gli strumenti di automazione si occupino dell’esecuzione operativa.