El Excel de tu red miente: cómo montamos una fuente de verdad con NetBox

Hay una pregunta que descoloca a casi cualquier empresa: ¿qué hay conectado en el puerto 23 del switch de la planta baja? La respuesta honesta suele ser un silencio, seguido de «lo tiene que saber Fulanito» y de una hoja de cálculo que alguien actualizó por última vez cuando aquello se montó. No es dejadez. Es que casi nadie ha decidido nunca dónde vive la verdad sobre su propia red.

Operamos red propia y mantenemos infraestructura de clientes, así que esta conversación la tenemos a menudo. Y la tenemos casi siempre en el peor momento: durante una avería, con alguien mirando un armario de comunicaciones y leyendo etiquetas que ya no coinciden. Este artículo va de la herramienta que usamos para que eso deje de pasar, NetBox, pero sobre todo va del criterio, que es la parte que no se instala.

Documentar no es escanear

Cuando alguien decide por fin poner orden, el primer impulso es siempre el mismo: lanzar un descubrimiento, barrer la red y volcar el resultado en la herramienta. Parece lo sensato y es justo lo contrario de lo que recomienda el propio proyecto. La documentación de NetBox lo dice con todas las letras: «NetBox pretende representar el estado deseado de una red frente a su estado operativo. Por eso, la importación automática del estado real de la red está firmemente desaconsejada».

Esa frase parece un detalle de manual y en realidad decide el resultado del proyecto entero. Si vuelcas lo que hay, conviertes cada error en norma: la VLAN que alguien creó a las tres de la mañana para salir del paso pasa a ser diseño, el cable provisional se documenta como definitivo y el equipo que quedó enchufado «hasta el lunes» entra en el inventario con todos los honores. A partir de ahí ya no puedes usar el inventario para detectar nada, porque coincide con la realidad por construcción, incluida la parte de la realidad que está mal.

La versión corta de nuestro criterio: el inventario guarda la intención; la monitorización mira la realidad; y el trabajo interesante está en la diferencia entre las dos. Una IP que aparece en la red y no en el inventario es una pregunta que alguien tiene que responder. Una IP que está en el inventario y no aparece por ningún lado, también. Si tu documentación se genera sola a partir de la red, esas dos preguntas no existen y te has quedado sin la parte útil.

Qué es NetBox, y qué no es

NetBox es un proyecto de código abierto bajo licencia Apache 2.0, con repositorio público desde febrero de 2016 y desarrollo muy vivo: en el momento de escribir esto, la última versión publicada es la 4.6.7, del 30 de julio de 2026, con entregas cada pocas semanas. Combina dos cosas que en muchas empresas viven separadas: la gestión de direccionamiento (IPAM) y el modelado de la infraestructura física (DCIM), es decir, sedes, armarios, unidades de rack, dispositivos, puertos y cables. Encima de eso trae registro automático de cambios, campos personalizados, API y disparadores de eventos para automatizar.

Igual de importante es la lista de lo que el proyecto declara que no es, porque ahorra discusiones: no es monitorización, no es un servidor DNS, no es un servidor RADIUS, no es gestión de configuración y no es gestión de instalaciones. Si lo compras esperando que sustituya a Zabbix o que configure tus switches, te vas a llevar un disgusto. Nosotros lo usamos junto a nuestra monitorización con Zabbix y SmokePing, no en su lugar: uno dice cómo debería estar montado aquello, el otro dice cómo está funcionando ahora mismo.

En cuanto a lo que hace falta para sostenerlo: PostgreSQL 14 o superior (la documentación ya avisa de que el soporte de la 14 desaparece en la versión 4.7 y pasará a exigir la 15), Redis, Python 3.12 a 3.14 y un servidor de aplicación tipo Gunicorn o uWSGI detrás de un proxy inverso. Traducido: es una aplicación de verdad, con su base de datos y su ciclo de vida, no un fichero que se guarda en una carpeta compartida. Eso es una ventaja y también una decisión que hay que tomar con los ojos abiertos.

La prueba de las tres preguntas

Antes de montar nada, esta es la prueba que hacemos para saber si la documentación existente sirve para algo. Tres preguntas, cronómetro en mano, sin llamar a nadie:

1. ¿Qué hay en esta dirección IP y quién la usa? No vale «creo que es la impresora de contabilidad».
2. Si apago este equipo, ¿qué deja de funcionar? Es la pregunta que separa un inventario de una lista de la compra.
3. ¿Quién cambió esto por última vez y cuándo? Sin registro de cambios, cualquier discusión sobre una avería acaba en memoria y en criterio.

Y una cuarta que en realidad es la que importa: ¿puede responderlas una máquina? Una fuente de verdad se distingue de un documento en que se consulta por API, no se lee. Mientras la respuesta viva en un PDF, en un diagrama de Visio o en la cabeza de alguien, no tienes documentación: tienes memoria distribuida entre varias personas y un dibujo bonito. La memoria se va de vacaciones, cambia de empresa y, con el tiempo, se equivoca con toda la buena fe del mundo.

Qué documentamos y qué decidimos no documentar

El error más caro de un proyecto de documentación no es documentar poco: es querer documentarlo todo. Un modelo enorme y desactualizado hace más daño que cuatro tablas correctas, porque genera confianza donde no la merece. Nuestra regla es simple: solo entra lo que alguien va a mantener, y para cada cosa que entra hay que poder decir en qué momento del trabajo se actualiza.

Y lo que dejamos fuera, con la misma convicción: la posición exacta de cada latiguillo en instalaciones que cambian cada semana, los inventarios de puestos de usuario que ya lleva otra herramienta, y cualquier dato que solo sirva para que el modelo parezca completo en una demostración. Documentar algo que nadie va a actualizar no es orden: es deuda con apariencia de orden.

La parte que no se instala: el proceso

Una fuente de verdad no se degrada de golpe. Se degrada un martes, cuando alguien resuelve una urgencia y no lo apunta porque «luego lo pongo». La segunda vez ya cuesta menos saltárselo. A la décima, la herramienta se ha convertido en un museo y todo el mundo vuelve a preguntarle a Fulanito, que además ahora tiene razón, porque la aplicación miente.

Lo que evita eso no es una funcionalidad, son tres decisiones aburridas: que el cambio en el inventario forme parte de la tarea y no sea un trámite posterior, que exista una revisión periódica que compare inventario y realidad —y que alguien tenga esa revisión en su agenda, con nombre y apellidos—, y que haya un procedimiento de baja tan claro como el de alta. Las bajas son el punto ciego universal: todo el mundo apunta lo que instala y casi nadie apunta lo que retira.

Este mismo razonamiento lo hemos aplicado en otros sitios y siempre acaba igual. Cuando escribimos sobre por qué «latest» no es una versión en nuestros propios despliegues, el fondo era idéntico: saber exactamente qué está corriendo no es una manía, es la única forma de poder revertir con criterio. Y cuando repasamos qué piden de verdad los cuestionarios de proveedor de NIS2, el inventario como fuente de verdad aparecía otra vez, esta vez en forma de pregunta de un cliente grande.

Cuándo NO hace falta montar esto

Si tienes una sede, dos switches y un firewall, no montes una aplicación con base de datos para documentarlo. Un fichero de texto en un repositorio, con historial de cambios y revisado de verdad, resuelve exactamente el mismo problema y no añade otro servicio que mantener, actualizar y respaldar. La pregunta no es cuántos equipos tienes, es cuántas personas distintas tocan la red y cuántas cosas cambian al mes. Cuando la respuesta a las dos deja de ser «una» y «pocas», el fichero deja de aguantar.

Tampoco lo montes si no vas a poner el proceso. Es la recomendación que más veces damos y la que menos gusta, porque implica reconocer que el problema no era la herramienta. Una fuente de verdad sin proceso de altas y bajas dura unos seis meses y luego es un motivo más de discusión durante las averías.

En everyWAN usamos NetBox como fuente de verdad de nuestra propia red, y el mismo criterio es el que aplicamos cuando diseñamos, documentamos y operamos la de otros: casi siempre dentro de un trabajo de consultoría más amplio, junto al diseño y la operación de redes y comunicaciones. No somos resellers de ninguna plataforma concreta y recomendamos según el caso, no según la comisión, así que a veces la conclusión honesta es que con un repositorio y disciplina vas servido. Y si tu red ya no cabe ahí, la pregunta con la que cerramos es la de siempre: si mañana no estuviera la persona que más sabe de tu red, ¿cuánto tardaría la siguiente en saber lo mismo? Si la respuesta se mide en semanas, no tienes un problema de documentación: tienes un riesgo operativo con nombre y apellidos.

Fuentes (verificadas): la cita sobre el estado deseado frente al operativo y la advertencia contra la importación automática del estado real, así como la lista de funciones (IPAM con paridad IPv4/IPv6, DCIM con elevaciones de rack y cableado, registro automático de cambios, campos personalizados, scripts y webhooks dirigidos por eventos) y la lista explícita de lo que NetBox no es (monitorización de red, servidor DNS, servidor RADIUS, gestión de configuración y gestión de instalaciones), de la introducción de la documentación oficial de NetBox. Los requisitos de instalación (PostgreSQL 14 o superior, con el aviso de que la 14 queda obsoleta y la versión 4.7 exigirá la 15; Redis; Python 3.12, 3.13 y 3.14; Gunicorn o uWSGI tras un proxy inverso), de la guía de instalación. La licencia Apache 2.0, la fecha de creación del repositorio (febrero de 2016) y la versión 4.6.7 publicada el 30 de julio de 2026, del repositorio público del proyecto y su historial de versiones, consultados el 6 de agosto de 2026. Son criterio y opinión nuestros, no de las fuentes: que volcar el estado descubierto convierte el error en norma, la separación entre intención y realidad, la prueba de las tres preguntas y su cuarta, la tabla de qué documentar y qué no, las tres decisiones de proceso y todo el apartado de cuándo no montar nada.