L'Excel de la teva xarxa menteix: com muntem una font de veritat amb NetBox

Hi ha una pregunta que descol·loca gairebé qualsevol empresa: què hi ha connectat al port 23 del switch de la planta baixa? La resposta honesta acostuma a ser un silenci, seguit d'un «això ho ha de saber en Tal» i d'un full de càlcul que algú va actualitzar per última vegada quan allò es va muntar. No és deixadesa. És que gairebé ningú no ha decidit mai on viu la veritat sobre la seva pròpia xarxa.

Operem xarxa pròpia i mantenim infraestructura de clients, així que aquesta conversa la tenim sovint. I la tenim gairebé sempre en el pitjor moment: durant una avaria, amb algú mirant un armari de comunicacions i llegint etiquetes que ja no coincideixen. Aquest article va de l'eina que fem servir perquè això deixi de passar, el NetBox, però sobretot va del criteri, que és la part que no s'instal·la.

Documentar no és escanejar

Quan algú decideix per fi posar-hi ordre, el primer impuls sempre és el mateix: llançar un descobriment, escombrar la xarxa i abocar-ne el resultat a l'eina. Sembla el més assenyat i és justament el contrari del que recomana el mateix projecte. La documentació del NetBox ho diu amb totes les lletres: «NetBox pretén representar l'estat desitjat d'una xarxa davant del seu estat operatiu. Per això, la importació automàtica de l'estat real de la xarxa està fermament desaconsellada».

Aquesta frase sembla un detall de manual i en realitat decideix el resultat de tot el projecte. Si hi aboques el que hi ha, converteixes cada error en norma: la VLAN que algú va crear a les tres de la matinada per sortir del pas passa a ser disseny, el cable provisional es documenta com a definitiu i l'equip que va quedar endollat «fins dilluns» entra a l'inventari amb tots els honors. A partir d'aquí ja no pots fer servir l'inventari per detectar res, perquè coincideix amb la realitat per construcció, inclosa la part de la realitat que està malament.

La versió curta del nostre criteri: l'inventari guarda la intenció; el monitoratge mira la realitat; i la feina interessant és a la diferència entre totes dues. Una IP que apareix a la xarxa i no a l'inventari és una pregunta que algú ha de respondre. Una IP que és a l'inventari i no apareix enlloc, també. Si la teva documentació es genera sola a partir de la xarxa, aquestes dues preguntes no existeixen i t'has quedat sense la part útil.

Què és el NetBox, i què no és

El NetBox és un projecte de codi obert amb llicència Apache 2.0, amb repositori públic des del febrer del 2016 i desenvolupament molt viu: en el moment d'escriure això, la darrera versió publicada és la 4.6.7, del 30 de juliol del 2026, amb lliuraments cada poques setmanes. Combina dues coses que a moltes empreses viuen separades: la gestió d'adreçament (IPAM) i el modelatge de la infraestructura física (DCIM), és a dir, seus, armaris, unitats de rack, dispositius, ports i cables. A sobre d'això porta registre automàtic de canvis, camps personalitzats, API i disparadors d'esdeveniments per automatitzar.

Igual d'important és la llista del que el projecte declara que no és, perquè estalvia discussions: no és monitoratge, no és un servidor DNS, no és un servidor RADIUS, no és gestió de configuració i no és gestió d'instal·lacions. Si el compres esperant que substitueixi el Zabbix o que configuri els teus switches, t'enduràs un disgust. Nosaltres el fem servir al costat del nostre monitoratge amb Zabbix i SmokePing, no en lloc seu: l'un diu com hauria d'estar muntat allò, l'altre diu com està funcionant ara mateix.

Pel que fa al que cal per sostenir-lo: PostgreSQL 14 o superior (la documentació ja avisa que el suport de la 14 desapareix a la versió 4.7 i passarà a exigir la 15), Redis, Python 3.12 a 3.14 i un servidor d'aplicació tipus Gunicorn o uWSGI darrere d'un proxy invers. Traduït: és una aplicació de debò, amb la seva base de dades i el seu cicle de vida, no un fitxer que es desa en una carpeta compartida. Això és un avantatge i també una decisió que cal prendre amb els ulls oberts.

La prova de les tres preguntes

Abans de muntar res, aquesta és la prova que fem per saber si la documentació existent serveix d'alguna cosa. Tres preguntes, cronòmetre a la mà, sense trucar a ningú:

1. Què hi ha en aquesta adreça IP i qui la fa servir? No val «em sembla que és la impressora de comptabilitat».
2. Si apago aquest equip, què deixa de funcionar? És la pregunta que separa un inventari d'una llista de la compra.
3. Qui va canviar això per última vegada i quan? Sense registre de canvis, qualsevol discussió sobre una avaria acaba en memòria i en criteri.

I una quarta que en realitat és la que importa: pot respondre-les una màquina? Una font de veritat es distingeix d'un document perquè es consulta per API, no es llegeix. Mentre la resposta visqui en un PDF, en un diagrama de Visio o al cap d'algú, no tens documentació: tens memòria repartida entre unes quantes persones i un dibuix bonic. La memòria se'n va de vacances, canvia d'empresa i, amb el temps, s'equivoca amb tota la bona fe del món.

Què documentem i què decidim no documentar

L'error més car d'un projecte de documentació no és documentar poc: és voler documentar-ho tot. Un model enorme i desactualitzat fa més mal que quatre taules correctes, perquè genera confiança on no la mereix. La nostra regla és simple: només hi entra el que algú mantindrà, i per a cada cosa que hi entra cal poder dir en quin moment de la feina s'actualitza.

I el que deixem fora, amb la mateixa convicció: la posició exacta de cada llatiguet en instal·lacions que canvien cada setmana, els inventaris de llocs d'usuari que ja porta una altra eina, i qualsevol dada que només serveixi perquè el model sembli complet en una demostració. Documentar una cosa que ningú no actualitzarà no és ordre: és deute amb aparença d'ordre.

La part que no s'instal·la: el procés

Una font de veritat no es degrada de cop. Es degrada un dimarts, quan algú resol una urgència i no ho apunta perquè «després ho poso». La segona vegada ja costa menys saltar-s'ho. A la desena, l'eina s'ha convertit en un museu i tothom torna a preguntar-ho a en Tal, que a sobre ara té raó, perquè l'aplicació menteix.

El que evita això no és una funcionalitat, són tres decisions avorrides: que el canvi a l'inventari formi part de la tasca i no sigui un tràmit posterior, que hi hagi una revisió periòdica que compari inventari i realitat —i que algú tingui aquesta revisió a l'agenda, amb nom i cognoms—, i que hi hagi un procediment de baixa tan clar com el d'alta. Les baixes són el punt cec universal: tothom apunta el que instal·la i gairebé ningú apunta el que retira.

Aquest mateix raonament l'hem aplicat en altres llocs i sempre acaba igual. Quan vam escriure sobre per què «latest» no és una versió als nostres propis desplegaments, el fons era idèntic: saber exactament què s'està executant no és una mania, és l'única manera de poder revertir amb criteri. I quan vam repassar què demanen de debò els qüestionaris de proveïdor de la NIS2, l'inventari com a font de veritat hi tornava a aparèixer, aquesta vegada en forma de pregunta d'un client gran.

Quan NO cal muntar això

Si tens una seu, dos switches i un tallafocs, no muntis una aplicació amb base de dades per documentar-ho. Un fitxer de text en un repositori, amb historial de canvis i revisat de debò, resol exactament el mateix problema i no afegeix un altre servei per mantenir, actualitzar i copiar. La pregunta no és quants equips tens, és quantes persones diferents toquen la xarxa i quantes coses canvien al mes. Quan la resposta a totes dues deixa de ser «una» i «poques», el fitxer deixa d'aguantar.

Tampoc el muntis si no hi posaràs el procés. És la recomanació que més cops fem i la que menys agrada, perquè implica reconèixer que el problema no era l'eina. Una font de veritat sense procés d'altes i baixes dura uns sis mesos i després és un motiu més de discussió durant les avaries.

A everyWAN fem servir el NetBox com a font de veritat de la nostra pròpia xarxa, i el mateix criteri és el que apliquem quan dissenyem, documentem i operem la d'altri: gairebé sempre dins d'una feina de consultoria més àmplia, al costat del disseny i l'operació de xarxes i comunicacions. No som resellers de cap plataforma concreta i recomanem segons el cas, no segons la comissió, així que de vegades la conclusió honesta és que amb un repositori i disciplina en tens prou. I si la teva xarxa ja no hi cap, la pregunta amb què tanquem és la de sempre: si demà no hi fos la persona que més sap de la teva xarxa, quant trigaria la següent a saber el mateix? Si la resposta es mesura en setmanes, no tens un problema de documentació: tens un risc operatiu amb nom i cognoms.

Fonts (verificades): la citació sobre l'estat desitjat davant de l'operatiu i l'advertiment contra la importació automàtica de l'estat real, així com la llista de funcions (IPAM amb paritat IPv4/IPv6, DCIM amb elevacions de rack i cablatge, registre automàtic de canvis, camps personalitzats, scripts i webhooks dirigits per esdeveniments) i la llista explícita del que el NetBox no és (monitoratge de xarxa, servidor DNS, servidor RADIUS, gestió de configuració i gestió d'instal·lacions), de la introducció de la documentació oficial del NetBox. Els requisits d'instal·lació (PostgreSQL 14 o superior, amb l'avís que la 14 queda obsoleta i la versió 4.7 exigirà la 15; Redis; Python 3.12, 3.13 i 3.14; Gunicorn o uWSGI darrere d'un proxy invers), de la guia d'instal·lació. La llicència Apache 2.0, la data de creació del repositori (febrer del 2016) i la versió 4.6.7 publicada el 30 de juliol del 2026, del repositori públic del projecte i el seu historial de versions, consultats el 6 d'agost del 2026. Són criteri i opinió nostres, no de les fonts: que abocar-hi l'estat descobert converteix l'error en norma, la separació entre intenció i realitat, la prova de les tres preguntes i la seva quarta, la taula de què documentar i què no, les tres decisions de procés i tot l'apartat de quan no cal muntar res.