Change & Automation guides

Change & Automation guides

rConfig sees every change through its backups, and it can also make changes: snippets push commands, Config Restore pushes back a stored block, and scheduled tasks run both on a timetable. These guides explain how those pieces fit into one change workflow, which choices matter, and where each one can mislead you. The step-by-step procedures stay in the main docs, starting with Configuration Diffs and Snippets.

The change loop

Each stage of a safe change maps to a feature with its own main docs page.

Change Pulse and Change Forge together make up Change Manager: Pulse gives visibility into what changed, Forge gives control over what is allowed to change. The Change Forge page describes its scope and current status.

Detection follows the backup schedule

rConfig doesn’t watch devices continuously. It finds a change when a backup runs and the new version differs from the last one. Change Pulse builds its timeline from those diffs, so a change made at 09:00 on a device backed up nightly shows up the next morning.

That makes backup frequency the main design decision. The docs suggest hourly backups for critical or fast-changing infrastructure and daily for stable estates, while warning against stacking heavy tasks at the same time. More frequent backups give tighter detection and finer-grained diffs, at the cost of load on rConfig and the devices.

Storage is the second trade-off. By default rConfig stores every backup as its own file, even when nothing changed, so every point in time can be retrieved and compared. The Hard Link option keeps that history while saving disk space, and per-command storage can be turned off for output you only collect for properties.

Three checks that are easy to confuse

CIC, diff exclusions and compliance policies all read the same backed-up text, but they answer different questions.

Getting CIC right comes before anything else. The Manual Compare tool and device diff views filter out Failed and Invalid configs by default, so a missing CIC definition quietly shrinks the versions you can compare. A truncated backup compared with a complete one produces a misleading diff.

Diff exclusions are the noise filter. Timestamps, uptime counters, NTP clock-period values and certificate blocks change on every backup and bury the one line that matters. The risk runs the other way too: a pattern that is too broad, or a greedy multiline match, hides real changes. Anchor patterns and keep them specific.

Reviewing change with Change Pulse

Change Pulse turns diffs into a review queue. It tracks configuration changes and, where state commands are collected, state changes such as interface status or routing table updates. Each change can be marked reviewed, flagged critical or annotated, and the dashboard counts unreviewed, overdue and critical changes alongside a review rate.

Two points to keep in mind when you build a review process on it:

• Marking a change reviewed records that someone looked at it. It doesn’t mark the change as authorised or revert it.
• Flagging a change as critical doesn’t send an alert on its own. Notification rules do that.

Where approvals live in an external ticketing system, the Change Forge page describes keeping device and timeframe details in the ticket and using Change Pulse to confirm the change was implemented as approved. Pulse notes can carry the ticket number.

Making changes with snippets

A snippet is a block of commands, written exactly as you would type them at the device console, optionally with {variables} filled in at send time. The snippet itself is simple. The decisions are about how you deliver it and how you know it worked.

By default a snippet push uses the same credentials as backups. From V8.2.2 a device can have a separate snippet credential set, which lets you keep a higher-privilege account for change only.

Knowing whether the device accepted it

Before V8.4.1, a snippet showed success if the session completed, even when the device rejected a line. Snippet error detection fixes that. It is switched on per connection template with a snippet_errors block of error and warning patterns. With it, rConfig sends one line at a time, checks each reply and reports Success, Success with warnings, Failed or Success (not checked).

The trade-offs to weigh:

• Stop at first error (on by default) protects dependent lines: nothing after a rejected line is sent. Turn it off when the lines are independent and you want every problem reported in one run.
• Error detection reports, it doesn’t roll back. Lines the device accepted before the rejected one stay applied.
• Line-by-line sending is slower, because rConfig waits for the prompt after each line. Long snippets need a template timeout to match.
• It works over SSH only. Telnet sends are always reported as not checked, as are templates without a snippet_errors block.
• Patterns that match normal output fail good sends, so test them against your own devices.

Backing out a change

There are two ways to undo a change, and the docs use both.

Config Restore suits incidents: find the last good version, select the block, check the generated commands and send them. It doesn’t create a backup or rollback point first, so take a backup before you use it. Each restore is kept in the device’s configuration history with the commands sent and the device’s response.

Pre-written rollback snippets suit planned changes, where the undo should be tested as carefully as the change itself.

Putting it together

The Snippets page describes backing up before and after every snippet deployment, either by hand or with three scheduled tasks a few minutes apart. Combined with the features above, a safe change looks like this:

1. A recent backup exists and its CIC status is Valid, so the “before” version can be trusted.
2. The snippet has been tested on a lab device, then one production device, then a small group.
3. The send runs with error detection on, so a rejected line shows as Failed rather than green.
4. A backup after the change captures the “after” version, and the diff shows exactly what moved.
5. Change Pulse records the change for review, and the review note carries the ticket reference.
6. If the result is wrong, a rollback snippet or Config Restore puts the previous block back.

Scheduled tasks can run each automated step. Smart groups are evaluated when the task runs, so a task picks up devices that newly match its rules without being edited. Snippet task reports include an Outcome column, and a failed send counts as a failure for tasks that email only on failure.

Related reference

• Change Manager overview
• Change Pulse
• Change Forge
• Config Diffs
• Diff Exclusions
• Snippets
• Snippet Error Detection
• CIC Definitions
• Config Restore
• Scheduled Tasks