The Network Audit Is Out of Date Before You Finish It

Every few years, something forces the question. An acquisition, a regulatory submission, a capacity crunch, an insurer, or an incident where nobody could say what the failed device was carrying.

So an audit is commissioned. Someone walks the floor with a laptop. Spreadsheets are reconciled against DCIM, DCIM against network inventory, network inventory against what the routers actually report. Months later a report lands, and for a short period the organisation knows what it owns.

Then a change window runs, three devices are swapped, a service is migrated, and the report starts drifting. Within a fortnight it is a historical document. Within a year somebody proposes an audit.

The audit is not the fix. It is the symptom.

What the audit is actually asking

Strip away the deliverable and every network audit is trying to answer four questions.

What do we have? Every device, its model, firmware, age and support status.

Where is it? Site, room, rack, rack unit. Which power feed, which circuit, which redundancy configuration.

What does it carry? Which platforms run on it, which VRFs and label-switched paths cross it, which customer services depend on it.

What happens if it fails? The reverse of the previous question, which is a different query and usually a much harder one.

These are reasonable questions. An operator should be able to answer them on a Tuesday afternoon. The reason an audit is required to answer them is that the answers live in different systems owned by different teams, and nothing joins them.

Two estates, two tools

The structural problem is almost always the same. DCIM knows about racks, power and cooling. Network inventory knows about VRFs, circuits and services. They are separate products, bought by separate teams, and neither can answer a question that crosses the line between them.

Which carrier services are affected if this rack loses its A feed? That question starts in one system and ends in the other. There is no join, so it becomes a meeting.

Because there is no join, the audit has to build one by hand, for the duration of the audit. That is most of the cost, and it is exactly the part that is thrown away when the report is filed. The next audit builds it again.

Why the reconciliation never holds

Three things guarantee the drift.

Nothing is computed. Capacity is estimated because it is not derived from what is installed. If a rack does not calculate its used and available rack units from the equipment actually mounted in it, then rack headroom is somebody’s judgement, recorded on a day. Judgements do not update themselves. The same applies to power draw and cooling load, which is why operators over-provision to stay safe and pay every month for stranded space, stranded power and stranded cooling that nobody can see.

Dependencies are recorded in one direction, if at all. Design documents record what a service needs. Almost nothing records what needs a given device. Since the question asked during a change window is always the second one, the answer gets assembled from memory by whoever has been there longest.

The record is a description, not a structure. An audit produces a document. A document cannot be queried, cannot roll up, and cannot tell you that it has become untrue. It looks equally authoritative on the day it is delivered and two years later.

What replaces the audit

Not a better audit. A model that does not need one.

The physical estate as a strict hierarchy, from site through building, floor, room and rack, with each level pointing to its parent. That sounds like bookkeeping until you need capacity to roll up, at which point it is the only thing that makes roll up possible.

Capacity computed rather than estimated. A rack that derives used, available and reserved rack units from the assets mounted in it, and reports its largest contiguous free space. Power circuits that record rated capacity and measured load, feed path, and whether they are utility, UPS or generator. Redundancy recorded explicitly as N, N+1, 2N, rather than assumed.

Assets placed to the rack unit, carrying purchase cost, depreciation, useful life and end of service life on the same record as their position and their ports. One record that finance, facilities and network engineering can all use, rather than three records that disagree.

The logical layer anchored to the physical one. Platform instances that link to the assets running them and the addressing they use. VRFs with their route distinguishers, label-switched paths with their protection and class of service, carrier services that link through to the ports and circuits underneath.

And dependencies recorded in both directions, so that tracing upward from a power circuit to the services it carries is a query rather than a discovery exercise.

The test

You do not need to evaluate anything to know whether you have this. Pick a rack. Ask which customer services would be affected if it lost its A feed, and see whether the answer arrives from a system or from a person.

If it arrives from a person, the audit will be commissioned again. Probably within two years, probably after an incident, and it will cost roughly what the last one did.

The point of a live model is not that it makes the audit faster. It is that the four questions the audit exists to answer stop being a project.

---

DemandFlow models the physical estate and the logical network as one connected record, so capacity rolls up and impact analysis is a query. Network asset management covers the digital twin from site to routing label, and platform lifecycle management tracks what the estate is running and when it stops being supported.