How to use
Quarterly, per site rather than per device, with the device inventory open beside the export repository. Two people finish it faster than one: somebody at the repository and somebody at a console.
Most items are answerable from records. Three are not, and they are the three this review exists for — the age of the newest export per device, an out-of-band login performed today, and the date an export was last applied to hardware it did not come from. Answered from memory, each of those is a fail.
Where the numbers come from
Export age is measured from the repository as the newest commit per device, joined to the inventory. The join is the point; the count on its own is a number about the collector, not about the estate.
The running-versus-boot difference is read from the device, in the platform’s own terms. It is not derived from two files in the repository, because many platforms render those two documents in different syntaxes and a naive comparison then flags every identical pair as different.
The out-of-band figure is a login performed during the review, with the emergency local account, over a path that does not cross the production data plane. A record that the path was commissioned is not this number.
The rehearsal date is the date somebody applied an export to hardware that was not its origin and reached a working configuration. Not the date of a plan, a review, or a successful export.
Access this needs
Read access to the export repository and to the device inventory it is compared against — and note where that repository actually lives, because whether it is reachable with routing and firewalling down is itself one of the items.
Console or out-of-band access to at least one device per platform, plus the emergency local credential. A reviewer who has to ask somebody else to perform the login can record the answer, but the item stays open until the login happens.
Read access to the licence and serial record, the vendor portal account and the certificate inventory. These usually sit outside the network team, which is why they are the items most often missing rather than most often wrong.
No ability to change a device is required. Nothing here is a configuration change; the single live action is an authenticated login over a path that is supposed to work.
What the review produces
A dated sheet naming the reviewer, the site, the device count and the disposition of every item, carrying three numbers: how many devices have an export newer than the threshold, how many currently show a running-versus-boot difference, and how many months since an export was last applied to different hardware.
Attach the list of devices with no export at all. It is the shortest list on the sheet and the one with the shortest path to harm, and it is usually closable before the next review.
Attach the re-derivation list too — the rules, NAT entries, aliases and tunnels that name addresses a recovery site will not have. Producing it calmly, once, is much cheaper than deriving it at 03:00 from a rule set somebody else wrote.
A failing item that is accepted rather than fixed needs a named acceptor. “The console path has not been exercised this year” is a decision somebody is making, and it should be one somebody has signed.
Sign-off
- Reviewer: ____ Date: ____
- Network owner: ____ Date: ____
- Service owner: ____ Date: ____
Every critical item must pass. A failing critical item is a blocker rather than a note for the next quarter: record the date, the reviewer, the disposition of every item that did not pass, and the name of whoever accepted the residual risk.