Skip to content

Network Configuration Snippets Concepts

Network Configuration Snippets - Automated Deployment & Change Management

Section titled “Network Configuration Snippets - Automated Deployment & Change Management”

After reading this page, you can explain what configuration snippets are in rConfig, understand the main use cases and design patterns, and describe how snippet execution works technically across UI, CLI, API, and scheduled task workflows.


Configuration snippets are reusable blocks of device commands stored in rConfig that can be deployed to individual devices or device groups simultaneously. They cover everything from simple two-line changes to complex multi-step procedures, providing a standardized method for applying configuration updates across heterogeneous network environments.

Once a snippet is created, tested, and validated, it becomes part of your operational toolkit, ready for rapid deployment whenever a similar change is required.

Simple example (Add VLAN):

conf t
vlan 100
name Engineering
exit
wr mem

Complex example (Configure SNMP with multiple steps):

conf t
snmp-server community rConfig123 RO
snmp-server host 10.1.1.100 version 2c rConfig123
snmp-server location "Data Center A"
snmp-server contact "netops@example.com"
exit
wr mem

Manual configuration changes require connecting to each device individually, entering commands, verifying the change, and saving the configuration. That approach is slow, error-prone, and hard to audit across large device fleets.

Snippets shift the model to centralized, automated deployment. The same commands are applied consistently across all target devices, removing the variability inherent in manual work. Every deployment is logged with a timestamp, user attribution, target devices, and execution results, which satisfies audit and compliance requirements without extra administrative overhead.


Syslog, SNMP, NTP, and AAA configurations often need to match a defined standard across all devices. Snippets let you treat that standard as code: create a snippet that embodies each required configuration, deploy it to all relevant devices, and verify compliance through automated reporting.

Infrastructure changes such as DNS migrations, NTP server replacements, and SNMP community updates follow a simple pattern: identify the change, identify affected devices, execute. Snippets package the change into a tested, reusable block that deploys to all affected devices simultaneously, compressing multi-day change windows into minutes.

New device deployments need consistent baseline configurations. Pre-built snippets for VLANs, routing protocols, security policies, and management access can be deployed to new equipment as part of the installation process, ensuring consistent builds and reducing reliance on individual engineer memory.

When a vulnerability requires an immediate configuration change across the infrastructure, snippets let security teams identify affected devices, create a remediation snippet, and deploy fixes network-wide within minutes. The combination of speed, accuracy, and full audit trails makes snippets well-suited for security operations.

Firmware Distribution and Upgrade Preparation

Section titled “Firmware Distribution and Upgrade Preparation”

Preparatory steps before a firmware upgrade (transferring image files, verifying checksums, setting boot variables, scheduling reloads) can be automated using snippets. rConfig can serve as a centralized host for verified firmware images, and snippets can automate the copy-and-verify process from rConfig to target devices.

The Configuration Restore feature integrates rConfig’s backup capabilities with the snippet engine. Two restore approaches are available. Full restore replaces the running configuration with a previously backed-up version. Partial restore leverages the snippet engine to apply specific configuration sections selectively, which is useful when you need to roll back one part of the configuration (for example, a BGP change causing routing issues) without touching recent changes elsewhere.

Restore operations queue through Horizon, execute via the standard connectivity process, and generate the same detailed activity logs as standard snippet deployments.


When a snippet deployment starts, rConfig creates a job for each target device and queues those jobs in Horizon. The queue manages concurrent execution based on configured limits, typically 10 to 50 simultaneous deployments depending on system resources and network capacity.

For each job, rConfig connects to the target device using the credentials and connection parameters defined in the device configuration, following the same process as configuration backups. Once connected, snippet commands execute sequentially, with rConfig waiting for the expected device prompt after each command before proceeding.

After all commands execute (or on failure), rConfig captures the complete device output, closes the connection, and logs the result. Success or failure status, execution duration, captured output, and any error messages are all stored in the activity log.

Snippet commands execute exactly as written, without preprocessing or interpretation. This prioritizes predictability: what you write in the snippet is what the device receives. Snippets must account for device-specific behaviors such as configuration mode entry, expected prompts, confirmation dialogs, and configuration persistence commands.

For Cisco IOS, this typically means beginning with conf t, executing configuration commands, exiting to privileged EXEC mode, and running wr mem or copy run start. Juniper uses configure and commit. Aruba uses configure terminal and write memory. Effective snippet design requires knowing these vendor-specific sequences.

Prompt detection is critical. After each command, rConfig waits for the device to return to a prompt state before proceeding. If the expected prompt does not appear within the configured timeout, the deployment fails. Understanding how prompts change when entering configuration mode or sub-configuration contexts is essential for reliable snippet operation.


The rConfig web interface offers three UI paths for snippet deployment.

Device-level deployment. From any device detail page, select and deploy a snippet directly to that device. Useful for device-specific troubleshooting or testing a new snippet before broader rollout.

Bulk deployment. The dedicated snippet deployment interface lets you select multiple target devices by individual selection, category, or tag. Parameters (if applicable) are entered once and applied to all selected devices.

Configuration Restore integration. When viewing a backed-up configuration, you can select specific sections and deploy them as ad-hoc snippets, combining the backup repository with the snippet engine’s reliability and audit capabilities.

The rconfig:send-snippet CLI command accepts snippet IDs and device IDs, enabling script-based deployment and integration with external automation. Two execution modes are available: standard mode queues jobs through Horizon (appropriate for production), and debug mode runs synchronously with real-time output (useful for troubleshooting).

The CLI also supports arbitrary snippet execution, where configuration commands are sent directly without creating a persistent snippet definition. This is useful for one-off changes or testing command sequences before formalising them as reusable snippets.

API endpoints mirror UI functionality: deploy pre-defined snippets, deploy parameterized snippets with supplied values, or execute arbitrary configuration commands without a pre-defined snippet. Common integration patterns include monitoring systems that trigger remediation snippets on alert, change management platforms that execute approved changes on workflow completion, and orchestration frameworks coordinating multi-vendor deployments.

Scheduled tasks provide time-based automation for snippet deployments. Task types include device-based, category-based, and tag-based scheduling. Use cases include periodic security baseline deployments, weekly configuration drift remediation, and maintenance window automation. Each task maintains independent configuration for frequency, target devices, and snippet selection.


Static snippets contain fixed commands that do not vary between deployments. They are the simplest and most common type, used for standardized configurations that apply identically to all target devices (universal syslog servers, corporate SNMP settings, standard AAA configurations).

Parameterized snippets include variables filled at deployment time, but only when deployed from the Device Page in the UI. A single parameterized snippet can handle multiple variations of similar configurations, reducing snippet library size while increasing flexibility. Common uses include interface configurations requiring device-specific IP addresses, VLAN creation with varying IDs and names, and user account creation with different usernames and privilege levels.

Multi-vendor environments require different command syntax for the same logical operation. A scalable approach is to tag snippets with vendor identifiers and deploy the appropriate snippet based on device type, keeping the snippet library organized while ensuring the correct syntax reaches each device.

Every significant configuration change should have a corresponding rollback snippet that reverses it. If a snippet adds VLAN 100, a companion snippet should remove VLAN 100. This provides immediate recovery capability if a change causes unexpected issues, reducing mean time to recovery during incident response.


New snippets should go through progressive testing: lab environment first if available, then a single non-critical production device, then a small group (5 to 10 devices), then the full target population. This progression surfaces issues before they affect large numbers of devices. Common problems include incorrect command syntax for specific OS versions, missing configuration mode transitions, prompt detection failures, and timing issues.

Every snippet should document its purpose, prerequisites, expected impact, and rollback procedure. Include the last testing date, verified OS versions, and any vendor-specific caveats.

Snippets need periodic maintenance as infrastructure evolves. OS upgrades may change command syntax, and architecture changes may render certain snippets obsolete. Quarterly reviews of the snippet library help identify snippets requiring updates and archive those no longer relevant.


For large deployments (500 or more devices), snippet jobs may queue and execute over 30 to 60 minutes rather than completing immediately. Understanding these scaling characteristics helps set realistic expectations for change window duration.

Snippets can make widespread configuration changes, so access controls are important. rConfig’s role-based access control (RBAC) system restricts snippet creation and deployment privileges. For snippets that modify security policies, credentials, or critical infrastructure, peer review or manager approval processes are worth considering.

Snippet deployments are configuration changes and should follow your organization’s change management processes: change request, impact analysis, approval, scheduling within maintenance windows, and post-change verification. Snippet automation makes change execution more efficient and reliable, but it does not replace change control.