Network Device Management Fundamentals

Network Device Management Fundamentals in rConfig V8

After reading this page, you can explain how command groups, templates, vendors, tags, credentials, and prompts work together in rConfig V8. You will also understand the available device-addition methods, how backups, diffs, and versioning are tracked, and how RBAC controls who can see which devices.

Core building blocks

Before adding devices, it helps to understand how the following pieces fit together. Every device belongs to a command group, connects using a template, and can carry tags, credentials, and prompts that control how it behaves.

Command groups

Command groups (formerly called Categories) determine what commands run against a device, which tasks can target it, and which compliance policies apply to it. Every device must belong to a command group, otherwise rConfig has nothing to run against it.

Commands

Commands are the CLI commands sent to a device during a backup, ranging from a single command to a full script. Each command supports its own options:

• Configuration Integrity Checks: confirm the returned output is valid configuration data
• Keep Unchanged Config: skip writing a new file when the output matches the previous run
• Change notifications: alert you when a command’s output differs from the previous version

Templates

Connection templates are YAML files that define how rConfig connects to a type of device. Write one template and reuse it across every device of that type. rConfig maintains a repository of community templates that can be imported directly.

Keep credentials out of templates

Never store real usernames or passwords inside a connection template. Keep connection timeouts between 5 and 30 seconds: shorter values cause false timeouts on slower devices, longer values delay failure detection.

Vendors

Vendors are labels for device manufacturers, such as Cisco or Juniper. rConfig ships with a starter list that you can extend, mainly used for filtering and reporting.

Tags

Tags group devices by location, function, team, or any other criteria that suits your environment. Scheduled tasks can target a tag instead of individual devices, for example backing up everything tagged production. Tags can also carry RBAC roles, which cascade to every device that carries the tag.

Device credentials

Device credentials store the usernames and passwords rConfig uses to connect to a device. Set these up before bulk-importing devices, otherwise imported devices will have no way to connect. For centrally managed secrets, see Vault Credentials Overview.

Prompts

Device prompts are the CLI prompts rConfig watches for to know a command has finished, such as Router# or Switch>. Prompts support regex (without delimiters), so escape special characters carefully.

Test prompt regex before deploying

Validate any regex prompt pattern on a site such as regex101.com before applying it to production devices. An incorrect pattern causes the backup to hang until it times out.

Adding devices to rConfig

rConfig supports several ways to add devices, depending on how many you need to add and whether the process should be automated:

• Add manually from the Devices table. Suitable for one or two devices.
• Clone an existing device. Every field copies over except the IP address and name.
• Use the REST API to create devices programmatically. See the Device API Reference.
• Import a CSV through Settings » Import/Export for bulk additions.
• Sync from an integration, if one is configured for your environment.

For bulk additions, prepare a CSV with the vendor, template, command group, and credential IDs you need, along with device names, IP addresses, overrides, prompts, and tags. The Device Import Workbook walks through this process in detail.

Saving a device immediately queues a download job. Check the Queue Manager and Activity Logs to confirm the job completes successfully.

Required device fields

Whether you add a device manually or via CSV, the following fields apply:

• Name and IP address: names can include letters, numbers, underscores, dots, and hyphens, with a minimum of three characters and no spaces. The IP address must be valid.
• Override ports: only needed if a device does not use the default port defined in its template.
• Vendor, command group, and template: all required. Model is optional but improves reporting.
• Tags and roles: control visibility and access. An SNMP toggle is also available for devices included in SNMP polling.
• Credentials: reference a stored credential record or enter values directly. From V8.2.2, you can attach a second credential set under Additional Configuration, used only for snippet pushes. This is useful when configs are collected with a read-only account but pushed with a higher-privilege one. If left empty, snippet pushes reuse the backup credentials.
• Prompts: the main prompt and enable prompt must be accurate, or downloads will hang until they time out.

Working with the device list

The device table supports search, filtering, column sorting, and shortcuts for filtering by up/down status.

Each row provides actions to assign roles, edit, clone, disable, or delete a device (delete requires confirmation). Opening a device shows its latest configurations, historical logs, a manual download trigger, cloning options, and a debug CLI command for troubleshooting connection issues. See Device Connectivity Troubleshooting for more detail.

Role-based access control (RBAC)

Device RBAC is enabled by default. The built-in admin role always sees every device. For other users, visibility depends on role assignments.

A role can be assigned directly to a device, or to a tag so that the role cascades to every device carrying that tag. If a device has no role matching a user’s permissions, that user cannot see the device.

Resyncing roles after an import

If role assignments fall out of sync, typically after a bulk import, run php artisan rconfig:update-device-roles to reapply the default admin role across all devices. See Roles and Permissions for more on managing roles.

How backups, diffs, and versioning work

During a backup, rConfig connects to the device, runs each command in the command group in order, captures the output, and stores it.

• Configuration Integrity Checks (CIC) confirm the output is usable configuration data. Disable this for commands that return non-configuration output, such as show version.
• Keep Unchanged Config avoids writing a new file when the output matches the previous run, while still recording that the version was checked.
• Change notifications alert you when a command’s output differs from the previous version.
• The diff engine can exclude patterns that change on every run (such as timestamps or uptime counters), adjust the amount of context shown, cap output size, and toggle sensitivity to case, whitespace, and line endings. See Configuration Diffs for the available settings.

Diff exclusion files start with a // description comment, followed by #[global] or #[command name] blocks containing regex patterns. Use the s and/or m flags for multiline matching; the g flag is not needed. See Diff Exclusions for example patterns.

The first backup of a device creates version 1 as the baseline. Each subsequent backup increments the version only if the output changed. With Keep Unchanged Config enabled, an unchanged run does not create a new file but still updates the version state in the audit log.

Keeping templates and connections healthy

Import templates from the maintained repository and customize them locally as needed. YAML is whitespace-sensitive, so keep indentation exact, add comments to document non-obvious settings, and test against lab devices first using the tools described in CLI Diagnostic Tools.

Set connection timeouts based on device responsiveness: slower devices may need 20-30 seconds, while faster devices can use 5-10 seconds. If you build a template that works well for your environment, it can be added alongside your existing entries on the Connection Templates page.

Keeping metadata clean

Consistent vendors, tags, and models keep filters and reports accurate. Devices labeled Cisco, cisco, and Cisco Systems as separate vendors will fragment your filters and reports, so pick one naming convention and apply it consistently.

The same applies to tags: a small, purposeful tag set makes device filtering and scheduled task scoping reliable. Because tags can carry RBAC roles, removing a tag from a device can also change who is able to see that device.

API Collections for cloud and HTTP-based devices

API Collections back up cloud controllers and other HTTP-based devices in the same way regular devices back up over SSH or Telnet. A collection defines a base URL, retry settings, an SSL verification toggle, a vendor, a command group, and tags.

Supported authentication modes are None, Basic Auth, Bearer token, API token, and Request token (exchanging a username and password for a session token). Each collection can define one or more endpoints, with per-endpoint filename overrides and a choice of GET or POST, and can be tested inline before scheduling.

API Collection downloads feed into the same diff engine, search, and compliance workflows as standard device configurations.

Best practices

• Design command groups around actual needs rather than placing every possible command in one group.
• Stage credentials, tags, and templates before bulk imports to avoid incomplete device records that need manual cleanup afterward.
• Check the Activity Logs after large imports to catch authentication failures and prompt issues early.
• Review metadata periodically: remove unused tags and vendors, and confirm diff exclusion patterns are not suppressing changes that matter.
• Test new templates and prompt patterns on non-production devices first before rolling them out broadly.

What’s next

• Add devices using the import workbook →
• Set up connection templates →
• Configure roles and permissions →