Network changes like code: drafts, checks and read-back

Most application teams stopped changing production from a laptop years ago. A change goes into a pull request, CI checks it, a colleague approves it, a pipeline deploys it at a sensible time, and monitoring confirms it did what it said. Network changes often still happen in a terminal session, typed from memory into the device that matters most, with a ticket written afterwards.

Configuration management in Tracix applies the same discipline to routers, switches and firewalls. This post walks through how a change moves, and the three things that make it safe: drafts that can't touch a device, checks that run before anyone approves, and a read-back that decides whether the change happened at all.

Intent is the source, the device is the target

Tracix keeps two views of every managed device. Running is what the device ran at its last backup, captured over SSH by a collector on the device's network. Intended is what you declare the device should run.

Intent is a list of requirements, not a full configuration file. Extra settings on the device don't count as drift unless you choose exact matching for a section. That keeps intent small enough to review, and lets you manage the parts of a configuration you care about without owning every line.

Most intent starts as a template, written once in vendor-neutral sections with typed variables:

[system/aaa]
ssh-version = 2
telnet = false

[system/ntp]
server-address = {{ ntp_server }}
prefer = true

Tracix translates each section into the platform's own commands, such as ntp server … on Arista EOS and set system ntp server … on Junos. When it can't translate a field for a platform, it blocks the field instead of quietly dropping it. Native configuration is still possible, in a !passthrough section aimed at exactly one platform, and the preview flags it.

Drafts: proposals that can't touch a device

Not every change starts with a person typing a template. Workflow agents can publish configuration proposals, and when Tracix has no deterministic translation for a device, Brain can research one. Both land under Network › Config Mgmt › Drafts, grouped by the devices they apply to.

A draft is review material: it never reaches a device by itself. An agent's draft becomes useful when you turn it into a template, and a translation when someone submits it. Either way, it then takes the same path as every other change.

Changes written by AI get two extra checks. An AI translation has to read back cleanly from the device's own configuration format before it can be submitted, and its change request needs an approver other than the person who submitted it.

Checks: the CI step

Every proposed change gets a preview before it can become a change request. The preview diffs the change against the device's intended configuration and checks it against the platform's schema. It also applies a few rules that no one should have to remember at 2 a.m.:

• It blocks a change that turns on Telnet, or that shuts down a management interface.
• It warns about a BGP change without an authentication key, and about native passthrough blocks, which skip intent validation.

The preview runs offline. It never contacts the device, so you can preview a change to 500 switches without opening 500 sessions. A baseline preview takes up to 10,000 devices in one run.

Compliance checks the other direction: not "is this change safe" but "is this device configured the way we require". Ten rules are built in, such as Telnet disabled, SSH version 2, Centralized AAA and No default SNMP community, and you can add text checks of your own. Tracix evaluates them against each device's latest backup, or against its intended configuration, and a check it can't evaluate is reported as Not evaluated, never counted as a pass.

Review: approvals and windows

Submitting creates a change request under Network › Config Mgmt › Changes, the equivalent of the pull request. It shows the preview, the proposed sections, the approvals so far, and whether maintenance windows apply.

Approving needs the approve permission, which admins hold by default, so the person who proposes a change and the person who approves it can be different people with different roles. One approval is enough today.

One caveat, stated plainly: approval comes from the device's backup policy. Policies you create in the console require it, but a device that no policy governs gets its change requests approved as soon as they are created. If you want every change reviewed, make sure every device sits under a policy.

Maintenance windows are weekly, with a start time, a duration and a time zone. A window can also be a blackout, which forbids changes while it is open. Deployment always respects windows and blackouts. The only override, an audited emergency override, applies to saving intent, never to pushing a change to a device.

Deploy through the collector next to the device

An approved change is saved as the device's new intended configuration first. The device itself doesn't change until someone selects Deploy to device. At that moment Tracix checks the approval, the windows and the platform's support again, then queues the job on the device's collector.

The collector asks your workspace for the credential the job needs, uses it in memory for that job, and connects to the device. Credentials live in a write-only vault, encrypted with AES-256-GCM: people can store and rotate them, but no screen or API returns a secret, to admins included.

How the change is applied depends on the platform:

Read-back: a change isn't done until the device says so

A pipeline that reports success because the deploy command exited with zero is lying a little. Tracix checks what the device actually runs afterwards.

Every change job captures the device's configuration before and after the change. The capture after the change goes through the same path as any backup: if the configuration changed, it becomes a new version in the device's history, and drift and compliance are evaluated against it. View execution and backup outcomes on the change request shows both.

Scoped writes go further, field by field. The collector reads the fields it is about to change, writes only those fields, and reads them back. If the read-back doesn't match, it restores the previous values, but only when the device still holds either the old or the requested values. Anything else, such as a value someone else changed in the meantime, leaves the job failed and marked as needing recovery, rather than guessing. It verifies the fields it touched; it isn't a transaction over the whole device.

The record carries on after the change. Devices that send their traps to a collector announce their own configuration changes, and Tracix records each one against the device. When an alert fires there, the problem it opens lists those changes under What changed, so the first question in an incident, "did anyone change anything?", already has an answer.

What it doesn't do yet

Scoped writes cover a deliberately small set of fields today: the hostname, the domain name, login and MOTD banners, the description or enabled state of an existing interface, and, over gNMI, a single deny entry in an access list that already exists. Tracix copies firmware images to devices and verifies their checksums there, but it never changes the boot image, runs an install command or reloads a device.

To try it, add a few devices to configuration management and follow Drafts and change requests. Compliance rules and Supported platforms cover the checks and what each OS family supports.