NetBox e IPAM: documentare la rete prima che sia troppo tardi

Ogni rete comincia con un foglio di calcolo. Una colonna con gli indirizzi, una con il nome dell'apparato, una con le note. Funziona finché gli apparati sono venti. Poi arriva il momento in cui nessuno sa più se una /29 è libera, chi ha assegnato quel VLAN ID, o quale porta dello switch alimenta il POP di un comune.

IPAM (IP Address Management) e DCIM (Data Center Infrastructure Management) sono le due discipline che risolvono il problema. NetBox le implementa entrambe nello stesso database.

Il problema del foglio di calcolo

Un foglio non ha vincoli. Nulla impedisce di assegnare due volte lo stesso /30 di transito, di dimenticare che una subnet è annidata dentro un'altra, o di lasciare una riga senza aggiornarla dopo una dismissione. Il risultato è la deriva: la documentazione descrive una rete che non esiste più, e a quel punto smette di essere consultata — il che accelera ulteriormente la deriva.

NetBox introduce un modello dati con integrità referenziale. Un prefisso appartiene a un aggregato, un indirizzo appartiene a un prefisso, un'interfaccia appartiene a un dispositivo, un dispositivo occupa unità rack in un sito. Le sovrapposizioni vengono segnalate, le assegnazioni duplicate rifiutate.

Le entità che contano per un ISP

L'errore più comune all'avvio è voler modellare tutto subito. Conviene partire da poche entità e popolarle bene.

Aggregati e prefissi. Gli aggregati sono i blocchi assegnati dal RIR — nel caso di un ISP europeo, quelli allocati da RIPE NCC. Sotto ogni aggregato si costruisce la gerarchia: transito, loopback, pool per il CGNAT, pool per le assegnazioni statiche ai clienti business, deleghe IPv6. NetBox calcola l'occupazione di ogni prefisso e mostra a colpo d'occhio lo spazio libero, cosa che rende banale rispondere a "abbiamo ancora indirizzi per questo POP".

Siti e rack. Un sito è un POP, un armadio stradale, una sala in colocation. Mappare le unità rack occupate evita la trasferta scoperta a metà: si sa in anticipo se c'è spazio e su quale unità montare.

Dispositivi e tipi di dispositivo. Il tipo descrive il modello (numero di porte, layout frontale, consumo), il dispositivo è l'esemplare con il suo numero di serie e la sua posizione. Definire i tipi una volta sola rende immediata l'aggiunta di apparati identici.

Interfacce e cavi. È la parte più noiosa da popolare e la più utile da avere. Sapere che la porta 12 dello switch in colo va al router e non a un cliente cambia l'esito di un intervento notturno.

VLAN e VRF. Un registro centrale dei VLAN ID per sito elimina le collisioni. Le VRF servono a separare spazi di indirizzamento che si sovrappongono legittimamente, come i pool privati di gestione.

Circuiti e provider. Transiti, peering, dark fiber: ogni circuito ha un identificativo dell'operatore, una banda e due terminazioni. Avere qui il codice del circuito significa non cercarlo in una vecchia email quando serve aprire un ticket.

Fonte di verità, non copia

Il punto che decide il successo dell'adozione è la direzione del flusso dati. Ci sono due approcci:

• Discovery: la rete viene interrogata e NetBox riflette ciò che esiste
• Source of truth: NetBox descrive lo stato desiderato e la configurazione degli apparati viene generata da lì

Il secondo è quello che porta valore reale, perché rende la documentazione un artefatto vivo: se non è in NetBox, non viene configurato. La combinazione tipica è NetBox più Ansible, con inventory dinamico che legge i dispositivi via API e template che generano la configurazione partendo dai dati modellati. Un cambio di descrizione di interfaccia diventa una modifica in NetBox seguita da un push, non una sessione SSH dimenticata.

L'approccio realistico per chi parte da una rete esistente è ibrido: si importa lo stato attuale con uno script di discovery, si corregge a mano ciò che non torna, e da quel momento si applica la regola che ogni modifica passa prima dal database.

Errori ricorrenti nell'adozione

• Popolare tutto in una volta. Meglio cominciare da prefissi e circuiti, che danno beneficio immediato, e aggiungere rack e cablaggi in seguito.
• Usare i campi descrizione come discarica. NetBox supporta custom field e tag: un dato che serve filtrare deve essere un campo, non testo libero.
• Non definire chi scrive. Se metà del team aggiorna NetBox e metà no, si torna al foglio di calcolo con più passaggi.
• Ignorare il journal. Ogni oggetto accetta annotazioni datate: è lì che va la storia degli interventi, non in un file separato.
• Backup trascurato. NetBox gira su PostgreSQL: il dump del database va nel piano di backup come qualsiasi altro sistema critico, e va testato il ripristino.

Alternative

NetBox non è l'unica opzione. phpIPAM è più leggero e si concentra solo sugli indirizzi, con una curva di apprendimento minore ma un modello dati meno ricco. Nautobot è un fork di NetBox orientato all'automazione, con un motore di job integrato. Per reti molto piccole un IPAM integrato nel firewall può bastare. La scelta dipende da quanto si intende automatizzare: se l'obiettivo è generare configurazioni, serve un modello dati completo e un'API solida.

In Velix il registro degli indirizzi e degli apparati è il punto di partenza di ogni attivazione: le deleghe IPv6, le assegnazioni statiche ai clienti business e le terminazioni di circuito nascono dal database e non da un file locale. È anche il motivo per cui una richiesta di indirizzi aggiuntivi su un servizio business si evade senza dover ricostruire a posteriori cosa era stato assegnato.