Un vivace dibattito si è acceso dopo il Networking Field Day 23, dove abbiamo presentato IP Fabric a un gruppo di delegati e a centinaia di avidi spettatori online. Potevamo classificare la nostra soluzione come una “fonte della verità” per la rete? La conclusione è stata “Sì e no”. Perché questa incertezza e cosa significava davvero la domanda? Ho tentato a venirne a capo!
Qual è la “Source of Truth”?
L’automazione di rete ha fatto molta strada. Un tempo gli script CLI creati per “mail merge” si avviavano in rete attraverso una sessione telnet. Ora sofisticate piattaforme d’automazione catturano lo stato desiderato e, attraverso modelli di configurazione, funzioni, moduli e API, trasmettono quello stato ai dispositivi di rete (se siete fortunati, lo fanno rollare di nuovo se non è completo). Dovete solo stabilire e registrare quali caratteristiche e parametri abilitare per trasmetterli ai vostri dispositivi.
Così si crea un database (fogli di calcolo, SQL, Data Center Infrastructure Manager-DICIM) o un sistema IPAM (IP Address Management) contenente tutte le caratteristiche e i parametri. I vostri modelli sono creati partendo dai dati contenuti nella configurazione prevista dal sistema. Ciò si definisce “Source of Truth”, SoT (talvolta “Single Source of Truth”, SSoT).
Esiste solo un luogo per memorizzare i dati: la fonte di riferimento finale della configurazione desiderata. Aggiornandola, si manifesta l’intenzione implicita che la configurazione di rete vada modificata. Di solito queste informazioni sarebbero controllate e tracciate, spesso usando Git o un Version Control System simile.
Quando una SoT non è una SSoT?
Quando non contiene tutte le informazioni in un unico luogo! Una Single Source of Truth può essere semplicemente un segnaposto o un proxy per la raccolta di fonti di riferimento per i singoli pezzi del puzzle dei dati di rete.
Si può utilizzare un sistema IPAM per registrare lo schema di indirizzamento IP definitivo che si vuole utilizzare o un CMDB per tracciare i dettagli dell’inventory dei dispositivi di rete. Questi sarebbero indicati come “Systems of Record”. In definitiva, l’automazione di rete deve poter accedere alle informazioni da entrambe queste fonti per definire le configurazioni. Perciò una SSoT comprimerebbe queste informazioni come richiesto.
Quindi IP Fabric è una SoT? O una SSoT?
Secondo la definizione convenzionale, non esattamente, poiché i dati di inventory, configurazione e stato in IP Fabric raccolti dai dispositivi di rete, non rappresentano lo stato previsto, che non può essere cambiato o aggiornato manualmente. IP Fabric costruisce degli snapshot indipendentemente dal vendor, riflette (con gran dettaglio) l’operatività dello stato della rete in un determinato momento, è interrogabile tramite Web UI o API, sia visivamente che a inventario. Pertanto ed essere memorizzato non è lo stato previsto, ma lo stato effettivo.
Perciò: “No”!
Ma non finisce qui, perché insieme ai dati della rete, possiamo costruire una serie di controlli di intent verification. Usiamo filtri e classificazioni sui dati per verificare che la rete sia conforme a uno stato previsto. Per esempio, possiamo assicurarci che tutti i dispositivi di rete siano configurati con uno specifico set di parametri di gestione. Verifichiamo che NTP, SNMP e syslog corrispondano a determinati criteri per ogni snapshot e presentiamo un rapporto di conformità.
Gli oltre 100 controlli di verifica incorporati forniti con la piattaforma vanno dal più semplice (ad esempio controllando dove la VLAN 1 è in uso) al più complesso (ad esempio assicurando che la radice dello Spanning Tree e i gateway attivi FHRP siano allineati), senza tralasciare tutto ciò che è nel mezzo (ad esempio controllando le dimensioni MTU agli estremi di un collegamento).
I controlli di verifica sono eseguiti su ogni snapshot, ci forniscono un modo per convalidare l’intent e lo stato della rete costantemente.
Quindi: “Una sorta di”?
Eseguiamo anche controlli simulati del percorso end-to-end ad ogni snapshot. Questo ci permette di convalidare che i percorsi siano quelli attesi e che le regole dei firewall consentano solo le connessioni previste.
Tutti questi controlli intent verification sono costruiti sia tramite Web UI, sia tramite l’estesa API REST di IP Fabric. Questo ci fornisce la possibilità di aggiornare le intent verification in IP Fabric mentre si effettua l’esecuzione delle configurazioni dai dati di stato previsti, confermando così ad ogni snapshot che lo stato corrisponda all’intento originale dalla SoT.
Si tratta della nuova funzione webhooks di IP Fabric, che ci permette di notificare una piattaforma esterna quando i controlli di verifica sono completati. Può essere utilizzata per implementare un meccanismo di allarme non appena lo stato effettivo si allontana da quello previsto.
Una SSoT dedicata è la soluzione ottimale
In IP Fabric confrontiamo l’intento con lo stato della rete fotografato durante lo snapshot. Se per qualche ragione operativa una parte della rete è in down, o si sceglie di eseguire uno snapshot parziale per convalidare un cambiamento in un’area della rete, allora si otterranno solo dati parziali. Ciò non è utile per esprimere l’intent su tutta la rete.
L’ideale è utilizzare IP Fabric in tandem con una SoT dedicata come il progetto open-source Netbox. IP Fabric verrebbe così utilizzata per la convalida incrociata che i dati nella SoT siano corretti e aggiornati. Questo fa di IP Fabric effettivamente un System of Record per lo stato attivo della rete. Una piattaforma di automazione come Ansible potrebbe quindi essere utilizzata per eseguire le configurazioni.
Utilizzando l’API, le intent verification rule di IP Fabric possono essere costruite a partire dai dati definiti nella SoT, per confermare che la configurazione e i comportamenti della rete corrispondano all’intento espresso nei modelli. Se lo stato non corrisponde all’intent, si usano i webhook per notificare alla piattaforma di orchestrazione/automazione che è necessario apportare modifiche. Quindi non verrà solo automatizzata la configurazione dei dispositivi di rete dalla SoT ma anche la configurazione di IP Fabric!
Conclusione
In base alle attuali definizioni accettate, IP Fabric non sarebbe considerato una “Single Source of Truth” per lo stato previsto. Sarebbe più precisamente un System of Record per lo stato della rete esistente, utilizzato insieme a una SSoT per misurare la conformità all’intent e, se necessario, attivarsi per correggere qualsiasi deriva.
Non perdetevi il prossimo articolo, dove parleremo dell’Intent-Based Networking in modo più dettagliato!
Se avete trovato utile questo articolo, continuate a seguire il nostro profilo LinkedIn o il Blog, dove pubblicheremo altri contenuti. Se desiderate vedere con i vostri occhi come IP Fabric può aiutarvi a gestire la vostra rete più efficacemente, contattateci visitando il nostro sito www.ipfabric.io.
