Su configuración cumple y su red sigue rota

El informe que dice que todo está bien

Imagine el resultado de una auditoría de cumplimiento sobre un switch de distribución. Ciento dieciséis pruebas de configuración, ciento dieciséis aprobadas. Cien por ciento. El estándar de la organización se cumple línea por línea: los servidores de tiempo son los correctos, la lista de acceso a la administración está aplicada, el protocolo de árbol de expansión tiene la prioridad que le toca, el registro de eventos apunta a donde debe.

Ese mismo switch tiene tres interfaces caídas. Tres interfaces que participan en el protocolo de ruteo interno, declaradas en la configuración, presentes en el estándar, y abajo.

La auditoría de configuración no las ve, y no es un defecto de la auditoría: es su definición. La configuración está bien. Lo que está mal es otra cosa.

El cumplimiento de configuración responde «¿está bien escrito?». No responde «¿está funcionando?».

Dos preguntas distintas sobre el mismo equipo

Conviene separarlas con claridad, porque las herramientas del mercado casi siempre contestan una sola y dejan creer que contestaron las dos.

El cumplimiento de configuración compara el texto de la configuración activa contra una intención declarada. Detecta lo que falta, lo que sobra y lo que difiere. Es una comparación estática y determinista: la línea está o no está. Sirve para auditorías, para control de cambios y para demostrar que un estándar se aplica de forma pareja en toda la red.

El cumplimiento de estado compara la operación real contra lo que se espera de ella. Interfaces arriba, sesiones del protocolo de puerta de enlace establecidas, vecinos del protocolo interno formados, rutas presentes en la tabla, uso de procesador y memoria bajo umbral, alcanzabilidad confirmada. Es dinámico: la respuesta puede cambiar entre dos consultas seguidas sin que nadie haya tocado un comando.

Una red puede aprobar la primera y reprobar la segunda. También al revés, que es menos intuitivo: un enlace puede estar arriba y pasando tráfico con una configuración que viola el estándar de seguridad de la organización. Funciona hoy y es un hallazgo de auditoría mañana.

Por qué correlacionarlas cambia lo que puede afirmar

Cada una por separado deja un hueco que la otra llena, y ahí está el valor real.

Un hallazgo de estado sin configuración es una alarma sin causa. «La sesión con el vecino 192.0.2.10 está caída» le dice que algo pasa, no por qué. Puede ser un enlace físico, una lista de acceso que filtra el puerto, una dirección de origen que dejó de coincidir, o el vecino que se reinició. Sin la configuración al lado, empieza la sesión de diagnóstico a mano que el sistema de monitoreo debía haberle ahorrado.

Un hallazgo de configuración sin estado es una suposición. «Falta el servidor de tiempo secundario» es cierto, pero no dice si el primario está sincronizando. Puede ser irrelevante o puede ser que el equipo lleve semanas con la hora corrida y todos sus registros sean inútiles para una investigación.

Juntas, la afirmación cambia de naturaleza. Deja de ser «hay un problema» y pasa a ser «esta interfaz está caída, participa en el protocolo interno según esta línea de configuración, y por eso estas tres redes no se están anunciando». Eso es un diagnóstico, y se puede accionar sin abrir una sesión contra el equipo.

La configuración explica el estado. El estado valida la configuración. Por separado, cada una miente por omisión.

Por qué casi nadie lo hace

No es por falta de ganas. Es que cuesta, y el costo está en tres lugares distintos.

• Son dos recolecciones diferentes. La configuración se obtiene con un método —interfaz de programación, protocolo de gestión de red, respaldo— y el estado operativo con otro: comandos de consulta, contadores, tablas de vecinos. Sostener los dos caminos, en cada fabricante, es el doble de superficie que mantener.
• Relacionarlas exige entender el modelo de cada plataforma. Para afirmar que una interfaz caída afecta a un protocolo hay que saber que esa interfaz está declarada en ese protocolo, y eso se dice distinto en cada fabricante. No basta con cruzar nombres.
• El estado se degrada rápido. Un informe de configuración de la semana pasada sigue siendo mayormente válido. Un informe de estado de la semana pasada no vale nada. Obliga a una cadencia de recolección que un proceso manual no sostiene.

Por eso la mayoría de las herramientas elige un lado. Las de gestión de configuración hacen muy bien lo primero y no miran lo segundo. Las de monitoreo hacen lo segundo y no saben nada de intención declarada. El operador queda con dos consolas y la tarea de correlacionar en la cabeza, que es justo lo que no escala a las tres de la mañana.

Qué se puede responder cuando están juntas

Cuando la misma auditoría cubre las dos dimensiones, aparecen preguntas que antes requerían un ingeniero con sesión abierta:

• ¿Qué equipos cumplen el estándar de configuración y además están operando como se espera?
• De los hallazgos abiertos, ¿cuáles afectan al servicio ahora mismo y cuáles son deuda de configuración sin impacto inmediato?
• Después de esa ventana de mantenimiento, ¿la red quedó como estaba, en configuración y en operación?
• Este equipo que reprueba, ¿reprueba porque está mal configurado o porque algo de su entorno cambió?

La segunda pregunta es la que más cambia el día a día. Una lista de cien hallazgos sin priorizar se ignora. Una lista de cien hallazgos donde cuatro tienen impacto operativo confirmado se atiende esta tarde.

Cómo lo resuelve Oktavia

Oktavia ejecuta ambas dimensiones en la misma auditoría y sobre el mismo inventario. El cumplimiento de configuración compara contra la intención declarada por alcance —sitio, rol, plataforma, modelo o equipo— y señala la línea exacta que sustenta cada hallazgo. El cumplimiento de estado consulta la operación real: interfaces, vecinos de los protocolos de ruteo, sesiones establecidas, árbol de expansión, tablas de direcciones, uso de procesador y memoria, y alcanzabilidad.

El resultado se presenta por categorías, de modo que un puntaje de configuración en cien por ciento junto a un puntaje de estado por debajo es una señal legible y no una contradicción: dice exactamente que la red está bien escrita y no está funcionando como debería, que es la situación con la que abrimos este artículo.

Cuando un equipo no se pudo recolectar, sus pruebas quedan marcadas como omitidas y no como incumplidas. Un equipo inalcanzable no es un equipo que incumple: es un equipo del que no sabemos nada, y confundirlos infla el problema y esconde los hallazgos reales.

De la visibilidad al cumplimiento: cómo se ejecuta y se lee una auditoría completa.