Your configuration passes and your network is still broken

The report that says everything is fine

Picture the result of a compliance audit on a distribution switch. One hundred and sixteen configuration checks, one hundred and sixteen passed. One hundred per cent. The organisation's standard is met line by line: the time servers are correct, the management access list is applied, spanning tree has the priority it should, logging points where it must.

That same switch has three interfaces down. Three interfaces that participate in the interior routing protocol, declared in the configuration, present in the standard, and down.

The configuration audit does not see them, and that is not a flaw in the audit: it is its definition. The configuration is correct. What is wrong is something else.

Configuration compliance answers "is it written correctly?". It does not answer "is it working?".

Two different questions about the same device

It is worth separating them clearly, because tools on the market almost always answer one and let you believe they answered both.

Configuration compliance compares the text of the running configuration against a declared intent. It detects what is missing, what is extra, and what differs. It is a static, deterministic comparison: the line is there or it is not. It serves audits, change control, and proving that a standard is applied evenly across the network.

State compliance compares actual operation against what is expected of it. Interfaces up, border gateway sessions established, interior protocol neighbours formed, routes present in the table, processor and memory usage under threshold, reachability confirmed. It is dynamic: the answer can change between two consecutive queries without anyone touching a command.

A network can pass the first and fail the second. It can also happen the other way round, which is less intuitive: a link can be up and carrying traffic on a configuration that violates the organisation's security standard. It works today and it is an audit finding tomorrow.

Why correlating them changes what you can claim

Each one on its own leaves a gap that the other fills, and that is where the real value sits.

A state finding without configuration is an alarm with no cause. "The session with neighbour 192.0.2.10 is down" tells you something is happening, not why. It could be a physical link, an access list filtering the port, a source address that stopped matching, or a neighbour that rebooted. Without the configuration alongside it, you begin the manual troubleshooting session that the monitoring system was supposed to spare you.

A configuration finding without state is an assumption. "The secondary time server is missing" is true, but it does not say whether the primary is synchronising. It may be irrelevant, or the device may have been running with a skewed clock for weeks, making all of its logs useless for an investigation.

Together, the claim changes in kind. It stops being "there is a problem" and becomes "this interface is down, it participates in the interior protocol according to this configuration line, and that is why these three networks are not being advertised". That is a diagnosis, and it can be acted on without opening a session to the device.

Configuration explains state. State validates configuration. Apart, each one lies by omission.

Why almost nobody does it

It is not for lack of interest. It is expensive, and the cost sits in three different places.

• They are two different collections. Configuration is obtained one way — an API, a network management protocol, a backup — and operational state another: show commands, counters, neighbour tables. Sustaining both paths, on every vendor, is twice the surface to maintain.
• Relating them requires understanding each platform's model. To claim that a downed interface affects a protocol, you have to know that the interface is declared in that protocol, and that is expressed differently by every vendor. Matching names is not enough.
• State decays quickly. A configuration report from last week is still mostly valid. A state report from last week is worthless. It forces a collection cadence that a manual process cannot sustain.

That is why most tools pick a side. Configuration management tools do the first very well and never look at the second. Monitoring tools do the second and know nothing about declared intent. The operator is left with two consoles and the job of correlating in their head, which is exactly what does not scale at three in the morning.

What you can answer when they sit together

When a single audit covers both dimensions, questions become answerable that previously required an engineer with an open session:

• Which devices meet the configuration standard and are also operating as expected?
• Of the open findings, which affect service right now and which are configuration debt with no immediate impact?
• After that maintenance window, did the network come back as it was, in configuration and in operation?
• This device that fails — does it fail because it is misconfigured, or because something in its environment changed?

The second question is the one that changes day-to-day work the most. A list of a hundred unprioritised findings gets ignored. A list of a hundred findings where four have confirmed operational impact gets handled this afternoon.

How Oktavia handles it

Oktavia runs both dimensions in the same audit and against the same inventory. Configuration compliance compares against intent declared by scope — site, role, platform, model, or device — and points to the exact line backing every finding. State compliance queries actual operation: interfaces, routing protocol neighbours, established sessions, spanning tree, address tables, processor and memory usage, and reachability.

Results are presented by category, so a configuration score at one hundred per cent next to a lower state score reads as a signal rather than a contradiction: it says precisely that the network is well written and not working as it should, which is the situation this article opened with.

When a device could not be collected, its checks are marked skipped, not failed. An unreachable device is not a device that fails compliance: it is a device we know nothing about, and conflating the two inflates the problem and hides the real findings.

From visibility to compliance: how a complete audit is run and read.