Drafts and change requests

To change a device in Tracix, you declare what it should run, get that reviewed as a change request, and let the device's collector apply it. This page covers each step, and how to stage firmware images on devices.

How a change moves

1. Declare. Write the change as a baseline or template, ask Brain to draft it, or write native configuration by hand.
2. Preview. Tracix diffs the change against the device's intended configuration and runs its preview checks.
3. Request. Submitting creates a change request under Network › Config Mgmt › Changes.
4. Approve. An approver approves or rejects it.
5. Save intent. The approved change becomes the device's intended configuration. The device itself doesn't change yet.
6. Deploy. The device's collector applies the change. Tracix checks the approval, the maintenance windows and the platform's support again first.
7. Verify. A fresh backup shows what the device now runs, and compliance and drift use that backup.

Declare a change

Use a baseline or template

Open Network › Config Mgmt › Intent & templates. A baseline is a reusable set of requirements you apply to many devices, across vendors.

• Create baseline combines building blocks such as Secure remote access, Time synchronization, Remote logging, Centralized authentication, Login notice, Remove default SNMP communities and Management interface. Build a network baseline starts you with secure access, time and logging.
• Write a template · No AI opens the template editor for your own declaration. Any baseline or building block also offers View source / Customize, which saves your changes as a separate copy.

A template declares sections and their fields, with named variables in double braces:

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

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

Variables are a string, number, boolean, IPv4 address or a choice from a list, each with an optional default. Tracix translates a vendor-neutral section into each platform's commands, for example ntp server … on Arista EOS and set system ntp server … on Junos, and blocks fields it can't translate rather than dropping them. To send native configuration instead, start a section with !passthrough and target exactly one platform; native sections aren't translated between vendors. Templates support variable substitution only, not loops, conditions or filters.

To apply a baseline, select Use baseline (or Use on a building block) and work through the three steps:

1. 1

   Configure baseline

   Enter the values the baseline needs. Under Advanced matching and normalized intent, each section is matched as Required settings by default, which allows extra configuration on the device. Choose Exact section only when the baseline owns the whole section.

2. 2

   Select fleet

   Filter by site, platform, collector or tag, select the devices, and select Preview. Previews check every selected device and change nothing. One run takes up to 10,000 devices and keeps going on the server if you leave the page.

3. 3

   Review coverage

   Each device lands in an outcome, such as Ready for review, or Needs research when Tracix has no deterministic translation for it yet. Inspect a device to see its translated configuration and preview checks, then select Submit for review to create change requests for the devices that are ready.

For a Needs research device, select Research this device to have Brain propose a translation. An AI translation must read back cleanly from the device's own configuration format before it can be submitted, and it always needs an approver other than the person who submitted it.

Ask Brain

On a device's Generate tab, describe the change in plain language and select generate intent. Review the proposed sections and preview checks, then select submit for approval. Generating needs an AI model connected to your workspace; see Brain.

Write native configuration

On a device's Manual tab, paste configuration in the device's own syntax, select dry-run to preview it, then submit for approval. Configuration written here is manually owned, so it never counts as drift.

Drafts

Network › Config Mgmt › Drafts collects configuration proposals that workflow agents publish and translation research produces, grouped by the devices they apply to. Drafts are review only: select Create template on an agent's draft to turn it into a template, then apply it like any other.

Preview checks

Every proposed change gets an offline preview before it can become a request. The preview diffs the change against the device's intended configuration, checks it against the platform's schema, and:

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

The preview doesn't contact the device. The device validates the change when the collector applies it.

Approve a change request

Open Network › Config Mgmt › Changes and select a request. It shows the preview, the proposed sections, the approvals so far, and badges for whether approval is required and whether maintenance windows apply. Enter an optional Note, then select approve or reject.

• Approving needs the approve permission, which admins have by default. One approval is enough.
• A request for an AI translation needs an approver other than its author.
• When no backup policy governs the device, or its policy doesn't require approval, the request is approved as soon as it is created. Policies you create in the console require approval.

To work through many requests at once, use Bulk intent review at the top of Changes: select requests, then Approve or Save intent for them. Bulk actions never deploy.

Maintenance windows

On Changes, select maintenance windows, then add window. A window is weekly: enter a Name, choose the days, and set a Start (HH:MM), a Duration (min) and a Timezone, such as Europe/Berlin.

• Turn on Blackout (forbid changes during this window) to block every change while the window is open.
• A backup policy can also list allowed windows, and its devices' changes then run only inside one of them. The policy editor doesn't set allowed windows yet; Brain can set them for you. Policies created in the console list none, so only blackouts apply to them.

Save and deploy

1. 1

   Save the approved intent

   On an approved request, select Save approved intent. Outside an allowed window or inside a blackout, saving is refused; an admin can tick Emergency override (execute outside the maintenance window — audited) to save anyway. The request now reads Intent saved, and the device is unchanged.

2. 2

   Deploy to the device

   Select Deploy to device. Tracix checks the approval, the maintenance windows and the device's platform support again, then queues the change on the device's collector. The emergency override doesn't apply here: deployment always respects blackouts and allowed windows.

3. 3

   Check the outcome

   Select View execution and backup outcomes to follow the job in Activity. The change is confirmed once a fresh backup shows the device running it.

Saving and deploying need the apply permission, which admins have by default. push to device on a device page deploys its current intended configuration with the same checks.

How the collector applies a change

A scoped write changes only the fields it names: the hostname, the domain name, the login and MOTD banners, and the description or enabled state of an existing interface. Over gNMI it can also add or remove a single deny entry for an address in an ACL that already exists on the device. The collector reads those fields before writing, writes only them, and reads them back. If the readback doesn't match, it restores the previous values when it safely can, and otherwise marks the job as needing recovery. To use scoped writes, set the device's protocol under Connection settings; the collector must be on a release that supports them. See Supported platforms.

Stage firmware images

Tracix can copy a firmware image to devices and verify it there. It doesn't install the image.

1. 1

   Upload the image

   Open Network › Config Mgmt › Images and select Upload image. Choose the Platform, enter the Version, pick the Image file (up to 8 GiB), and paste the vendor's SHA-512 checksum. Optionally list Supported models, such as 7280R*, a Min source version, and mark it Recommended or End-of-life. The image goes to private storage in your workspace.

2. 2

   Check eligibility

   Select the image to see which devices are eligible and why others are excluded. Eligibility compares platform, model and version; it doesn't certify that a device can install the image.

3. 3

   Stage it

   Under Stage image on devices, select the devices, keep Responsible collector for each device or pick a collector, and enter the Destination file path on each device, such as /mnt/flash/image.swi, and the SSH / SFTP port. Select Stage and verify.

Each device gets its own job. The collector downloads the image, checks its size and SHA-512 checksum, and keeps a verified copy in its cache, so staging the same image on several devices downloads it once. It then copies the image to the device over SFTP, reads it back to check the checksum and size again, and moves it into place. An existing file with the same checksum is reused, and a different file at the destination is never overwritten.

Staging needs a bound SSH login credential, a device that supports SFTP with free-space reporting, a collector on a release that supports staging, and the apply permission.

Next steps