Network Device Commands Configuration for rConfig V8

rConfig V8 Commands: Complete Guide to Network Device Configuration Management

Note

Refer to the Command Groups documentation to understand how Command Groups and commands work together to organize your device backup workflows.

Commands are the fundamental building blocks of rConfig’s configuration management workflow. They represent the specific instructions sent to network devices during backup operations, with each command’s output captured and stored for configuration management, compliance verification, and change tracking purposes.

Understanding how commands work within rConfig is essential for effective network configuration management. Commands work in conjunction with Command Groups (previously known as Categories) to define what information gets retrieved from your network devices and how that information is processed, compared, and stored.

Understanding Commands in rConfig

What Are Commands?

In rConfig V8, a command is more than just a text string sent to a device. Each command is a configured entity with specific behaviors, comparison rules, and processing instructions. When rConfig executes a device backup, it sends each command in sequence to the device and captures the output for storage and analysis.

Commands can be:

Single Commands: Individual instructions that retrieve specific information from a device, such as show ip int brief or show version.

Command Sets: Multiple commands combined with line breaks between command strings. When line breaks are present, rConfig sends each command in the set sequentially and processes their outputs according to the command’s configuration.

Why Command Configuration Matters

Proper command configuration directly impacts:

Storage Efficiency: Through intelligent change detection and selective file saving, properly configured commands reduce disk space usage and database overhead.

Change Detection Accuracy: Advanced comparison options ensure that meaningful changes are detected while ignoring irrelevant variations like timestamps or dynamic counters.

Notification Relevance: Fine-tuned command settings ensure that alerts are sent only when substantive changes occur, reducing alert fatigue.

Compliance Verification: Configuration Integrity Checks (CIC) validate that retrieved configurations are complete and valid, critical for audit and compliance requirements.

Command Types and Examples

Understanding the different ways commands can be structured helps optimize your backup workflows for different scenarios.

#	Type	Command	Comment
1	Single Command	show ip int brief	Standard single command format. Must be unique, minimum 3 characters, maximum 255 characters. Special characters including pipes are supported.
2	Command Set	show clock\nshow version	Multiple commands with line breaks. All output downloads to a single configuration file. Use this approach when commands are logically related or when device performance requires grouping.
3	Complex Command	show running-config | section interface	Commands with pipes and filters are fully supported. Useful for retrieving specific configuration sections.

When to Use Command Sets vs. Individual Commands

Use Command Sets when:

• Commands retrieve logically related information
• Device response time benefits from reduced connection overhead
• Output should be stored in a unified file for comparison purposes
• Commands are always executed together in your operational procedures

Use Individual Commands when:

• Each command’s output requires independent change tracking
• Different comparison rules apply to different outputs
• Selective CIC validation is needed for specific commands
• Change notifications should trigger independently

Adding and Editing Commands

Step-by-Step: Creating a New Command

Prerequisites:

• Administrative access to rConfig V8
• Understanding of device command syntax for your network equipment
• Knowledge of which Command Group the command should belong to

Procedure:

1. Navigate to Commands in the main menu
2. Click the Add Command button
3. Enter the command string in the Command field
4. Assign the command to one or more Command Groups
5. Configure command behavior using the toggle switches
6. Set comparison options if the command requires specialized diff handling
7. Save the command configuration

Validation Steps:

• Verify the command appears in the commands table
• Confirm the command is associated with the correct Command Group(s)
• Test the command execution during a device backup to ensure proper output capture

Command Configuration Toggles

When a command is added to the database, three toggle switches control critical aspects of command behavior. Understanding these toggles is essential for optimizing your backup workflows and ensuring proper change detection.

Command Configuration Toggles

CIC Enabled Toggle

Configuration Integrity Check (CIC) Enabled: When enabled, rConfig performs validation on the command output to verify that a complete and valid configuration was retrieved. This check runs automatically at the end of the configuration download process.

When to enable CIC:

• Commands that retrieve running configurations or startup configurations
• Commands whose output is critical for compliance or audit purposes
• Commands where incomplete output would represent a backup failure
• Commands that should always return substantial configuration data

When to disable CIC:

• Informational commands that may return minimal output (e.g., show clock)
• Commands that retrieve status information rather than configuration
• Commands where output length varies significantly based on device state
• Commands used for monitoring rather than configuration backup

How CIC works: The integrity check evaluates the command output against expected patterns and thresholds. If the output appears truncated, empty, or malformed, rConfig flags the backup with a warning, allowing administrators to investigate potential collection issues.

Tip

For critical configuration commands like show running-config, always enable CIC to ensure backup completeness. For less critical informational commands, disabling CIC prevents false positive alerts.

Keep Unchanged Config Toggle

Keep Unchanged Config: When enabled, rConfig saves the configuration file only if the output has changed since the last time the command was executed. This feature addresses the challenge of storage efficiency in large-scale network environments.

Why this matters: In typical network environments, most device configurations remain static between backup cycles. Without selective saving, rConfig would create duplicate files for every backup operation, even when no changes occurred. This rapidly consumes disk space and increases database overhead.

When to enable:

• Commands that retrieve running configurations
• Commands where output is expected to remain stable unless configuration changes occur
• High-frequency backup schedules where most backups capture unchanged configurations
• Storage-constrained environments where disk space optimization is critical

When to disable:

• Commands that retrieve dynamic information (e.g., interface statistics, ARP tables)
• Commands used for monitoring or troubleshooting rather than configuration management
• Commands where you need a historical record of every execution regardless of changes

Storage impact example: In an environment with 1,000 devices backed up daily, if only 5% of devices change daily, enabling this toggle reduces storage requirements by approximately 95% for those commands.

Caution

Disabling this toggle for all commands will significantly increase storage consumption. Evaluate each command’s purpose and expected change frequency before disabling selective saving.

Change Notifications Toggle

Change Notifications: When enabled, rConfig sends email notifications when the command output changes compared to the previous execution. This feature provides real-time awareness of configuration changes across your network infrastructure.

When to enable:

• Critical configuration commands where changes require immediate attention
• Commands that monitor security-sensitive configurations
• Commands where unauthorized changes must be detected quickly
• Commands that track compliance-critical settings

When to disable:

• Commands that retrieve frequently changing information (e.g., interface counters)
• Commands where changes are expected and routine
• Test or development environments where change notifications would create alert fatigue
• Commands used for informational purposes rather than change tracking

Best practice: Enable change notifications selectively for commands that represent substantive configuration changes. Combine with comparison exclusions (documented below) to filter out benign changes like timestamps while still alerting on meaningful modifications.

Bulk Assign Commands

For organizations managing hundreds of commands across multiple Command Groups, the bulk assignment feature streamlines command organization and reduces administrative overhead.

When to Use Bulk Assignment

Initial deployment: When setting up rConfig for the first time and organizing existing commands into Command Groups.

Reorganization projects: When restructuring your Command Group hierarchy or consolidating categories.

Vendor-specific groupings: When assigning multiple vendor-specific commands to appropriate Command Groups simultaneously.

Workflow standardization: When implementing new backup workflows that require multiple commands to be grouped together.

Bulk Assignment Process

1. Navigate to the Commands section
2. Select multiple commands using the checkbox selectors
3. Click the Bulk Assign action
4. Choose the target Command Group(s)
5. Confirm the assignment
6. Verify that selected commands now appear in the target Command Group(s)

Note: Bulk assignment is additive. Commands retain their existing Command Group associations unless explicitly removed.

Compare Options

rConfig’s comparison engine provides granular control over how command outputs are analyzed for changes. These options address the challenge of distinguishing meaningful configuration changes from benign variations in device output.

Understanding the Comparison Challenge

Network devices often include dynamic information in their configuration output:

• Timestamps indicating when configurations were last modified
• Uptime counters that change continuously
• Session identifiers that vary between connections
• Dynamic routing information that updates frequently
• System-generated unique identifiers

Without intelligent comparison options, every backup would show “changes” due to these dynamic elements, creating alert fatigue and making it difficult to identify substantive configuration modifications.

Available Comparison Options

Click the Compare Options button for any command to access the comparison configuration interface.

Compare Options Button

Compare Exclusions

Compare exclusions allow you to specify lines of text or patterns that should be excluded from the comparison process. This is the most powerful tool for filtering out dynamic information while preserving detection of meaningful changes.

Use cases:

• Exclude timestamp lines from running configurations
• Filter out system uptime information
• Ignore certificate expiration warnings
• Exclude dynamic routing table entries from comparisons
• Filter build date information that changes with software updates

How it works: rConfig applies exclusion patterns before performing the diff operation. Excluded lines are removed from both the current and previous outputs before comparison, ensuring that only substantive changes trigger change detection.

See the Configuring Diff Exclusions section below for detailed implementation instructions.

Compare Context

Compare context specifies the number of unchanged lines to include before and after changed lines in diff output. This provides situational awareness about where changes occurred within the configuration.

Context values:

• 0 lines: Show only changed lines (most compact view)
• 3 lines (default): Standard context providing adequate situational awareness
• 5+ lines: Extended context useful for understanding changes in complex configurations

When to increase context:

• Large configuration files where change location matters
• Configurations where surrounding context helps understand the change’s impact
• Troubleshooting scenarios where you need to see what’s near the change

When to decrease context:

• Commands with frequent small changes across many lines
• Large configuration files where you want to focus only on changes
• Automated processing where context is not required

Length Limit

Length limit specifies the maximum number of lines to include in comparison operations. This addresses the challenge of comparing extremely large command outputs that could impact system performance.

Default: Unlimited (all lines compared)

When to set a length limit:

• Commands that return thousands of lines of output
• Commands that include large routing tables or ARP caches
• Performance-constrained environments
• Commands where only the first N lines contain configuration information

Important: Setting a length limit may cause legitimate changes beyond the limit to go undetected. Use this option carefully and only when necessary for performance reasons.

Caution

Length limits apply to comparison operations only. The complete command output is still stored in rConfig. This setting affects only change detection, not data retention.

Ignore Case

When enabled, the comparison treats uppercase and lowercase characters as equivalent. This addresses differences in command output casing across device types or firmware versions.

Enable when:

• Comparing configurations from devices that inconsistently capitalize output
• Handling vendor variations in command output formatting
• Managing mixed-vendor environments with different casing conventions

Disable when:

• Case sensitivity is meaningful in your configurations (e.g., passwords, variables)
• You need to detect case changes as substantive modifications
• Standard device output always uses consistent casing

Ignore Line Ending

When enabled, the comparison ignores differences between Unix-style (LF) and Windows-style (CRLF) line endings.

Enable when:

• Managing devices that use different line ending conventions
• Handling configurations edited on different operating systems
• Avoiding false positives due to line ending variations

Disable when:

• Line ending consistency is required for compliance
• You need to detect line ending changes as configuration issues

Ignore Whitespace

When enabled, the comparison ignores differences in spaces, tabs, and other whitespace characters.

Enable when:

• Devices inconsistently format output spacing
• Configuration formatting varies between firmware versions
• Whitespace differences are not meaningful in your context

Disable when:

• Whitespace is syntactically significant in configurations
• You need to detect indentation or formatting changes
• Precise configuration formatting must be maintained

Tip

Start with conservative comparison options (most filtering disabled) and enable options progressively as you identify sources of false positive change alerts. This approach ensures you don’t accidentally filter out meaningful changes.

Configuring Diff Exclusions

Diff exclusions provide precise control over what gets filtered from configuration comparisons. The exclusion system uses regular expressions to match and exclude specific patterns from diff operations.

Diff Exclusions Configuration Interface

Understanding the Exclusion Format

rConfig’s exclusion format is similar to the Policy Definitions format with specific adaptations for comparison operations. Each exclusion configuration consists of blocks that define where and how patterns should be applied.

Exclusion Block Structure

// Description of what this exclusion does
#[scope]
/regex pattern/
/another regex pattern/

Components:

Description line: Every block must begin with a description prefaced with //. This documents the exclusion’s purpose for future reference.

Scope definition: Defines where the exclusion applies, wrapped in #[brackets]. The scope can be global (applies to all commands) or a specific command name.

Regex patterns: One or more regular expression patterns that match lines to exclude. Each pattern must include delimiters (typically /pattern/) and any flags.

Global Exclusions

Global exclusions apply to all command outputs regardless of which command generated them. This is useful for patterns that appear consistently across multiple commands.

// Exclude timestamp lines from all commands
#[global]
/^! Last configuration change at .* by .*$/
/^! NVRAM config last updated at .*$/

Global exclusion use cases:

• Timestamp lines that appear in multiple command outputs
• System uptime information
• Build date and version information
• Standard header or footer text that changes frequently

Note

The first exclusion block must always use the #[global] scope. Additional blocks can then define command-specific exclusions.

Command-Specific Exclusions

Command-specific exclusions apply only to output from a particular command. The command name in the scope must exactly match the command as configured in rConfig, including spacing and capitalization.

// Exclude interface uptime from show ip interface brief
#[show ip interface brief]
/^.*uptime is .*$/

// Exclude crypto key timestamps from show run
#[show run]
/^crypto key generate rsa general-keys modulus \d+ label .* timestamp .*$/

Important: The command name in #[command name] must be identical to the command string in the database. If your command is show run , the scope must be exactly #[show run] with the trailing space.

Regular Expression Guidelines

Pattern requirements:

• Patterns must include delimiters (typically forward slashes: /pattern/)
• Patterns must be valid PHP-compatible regular expressions
• Use appropriate regex flags when needed (see flags section below)
• Escape special characters appropriately

Common pattern elements:

• ^ - Start of line
• $ - End of line
• .* - Match any characters (zero or more)
• .+ - Match any characters (one or more)
• \d - Match any digit
• \s - Match any whitespace
• [abc] - Match any character in set
• (pattern1|pattern2) - Match either pattern

Example Exclusion Configurations

Cisco IOS Exclusions

// Exclude timestamp and uptime information
#[global]
/^! Last configuration change at .* by .*$/
/^.*uptime is .*$/
/^Configuration last modified by .* at .*$/

// Exclude crypto certificate timestamps from show run
#[show run]
/^crypto pki certificate chain .*$/
/^ certificate \w+ \w+$/

Juniper JUNOS Exclusions

// Exclude system commit information
#[global]
/^## Last commit: .* by .*$/
/^## Last changed: .*$/

// Exclude interface statistics from show interfaces
#[show interfaces terse]
/^.*Last flapped: .*$/

Palo Alto Networks Exclusions

// Exclude dynamic timestamp fields
#[global]
/^Last update time: .*$/
/^Generated at: .*$/

// Exclude session-specific information
#[show system info]
/^vm-series-mode: .*$/
/^app-version: .*$/

Multiline Pattern Support

rConfig supports multiline regex patterns for excluding content that spans multiple lines. This addresses the challenge of filtering configuration blocks such as certificates, large sections, or multi-line constructs.

Understanding Multiline Regex Flags

s flag (dotall): Allows the . metacharacter to match newline characters. Without this flag, . matches any character except newlines. With the s flag, . matches everything including newlines, enabling patterns to span multiple lines.

m flag (multiline): Changes the behavior of ^ and $ anchors. Without this flag, ^ matches only the start of the string and $ matches only the end. With the m flag, ^ matches the start of each line and $ matches the end of each line.

Combined ms flags: Using both flags together is common for multiline exclusions where you need to match across lines and anchor to line boundaries within the multi-line content.

Multiline Exclusion Examples

Excluding Certificate Blocks:

Certificates in configurations often span dozens of lines. Excluding them requires matching from the certificate header through the footer.

// Exclude certificate blocks that span multiple lines
#[global]
/^set private-key "-----BEGIN ENCRYPTED PRIVATE KEY-----.*?-----END ENCRYPTED PRIVATE KEY-----"$/ms

// Exclude certificate chains in show run
#[show run]
/^crypto pki certificate.*?-----END CERTIFICATE-----"$/ms

Excluding Large Configuration Blocks:

Some configuration sections like routing protocol configurations span many lines but should be excluded from change detection.

// Exclude BGP router configuration blocks
#[global]
/^router bgp \d+.*?^!/ms

// Exclude interface configuration blocks
#[show run]
/^interface .*?^!/ms

Key syntax elements:

• .*? - Non-greedy match (match as little as possible)
• .* - Greedy match (match as much as possible)
• ^! - Match exclamation point at start of line (common configuration delimiter in Cisco IOS)

Best Practices for Multiline Patterns

Use non-greedy matching: Always use .*? instead of .* when matching across multiple lines. Greedy matching can capture far more content than intended.

// GOOD: Non-greedy matching stops at the first END marker
/^-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----$/ms

// BAD: Greedy matching might capture multiple certificates
/^-----BEGIN CERTIFICATE-----.*-----END CERTIFICATE-----$/ms

Anchor appropriately: Use ^ and $ anchors with the m flag to match specific line patterns within multiline content.

Test your patterns: Multiline patterns can be complex. Test them against sample configurations to ensure they match the intended content without over-matching.

Document complex patterns: Always include clear descriptions for multiline patterns explaining what they exclude and why.

Caution

Do not use the g flag in your regex patterns. PHP handles global matching differently than JavaScript. rConfig automatically processes all matches without requiring the g flag. Including it may cause unexpected behavior.

Performance Considerations

Single-line patterns vs. multiline patterns: Regular single-line patterns (without s or m flags) are processed line-by-line for optimal performance. Multiline patterns are processed against the entire configuration text, which is more resource-intensive but necessary for multi-line constructs.

Pattern efficiency: Write patterns as specifically as possible. Overly broad patterns with extensive use of .* can impact comparison performance, especially on large configurations.

Exclusion order: rConfig processes exclusions in the order they’re defined. Place the most commonly matched patterns earlier in the exclusion list for better performance.

Testing and Validation

After configuring diff exclusions, validate that they work as intended:

1. Trigger a backup of a device that uses commands with exclusions configured
2. Review the diff output to verify that excluded patterns do not appear
3. Verify change detection still functions for non-excluded content
4. Test edge cases such as patterns that might partially match unintended content
5. Monitor false negatives to ensure exclusions aren’t filtering legitimate changes

Tip

For detailed guidance on configuring diff exclusions, watch our video tutorial on YouTube which provides step-by-step examples and troubleshooting tips.

Best Practices

Command Organization

Use descriptive command names: When creating commands, use names that clearly indicate what the command does and what output it retrieves. This makes command management easier as your environment scales.

Group related commands: Assign commands to Command Groups based on logical relationships. Consider grouping by device type, configuration section, or operational purpose.

Standardize command syntax: Establish standard command formats across your organization. Consistent command syntax reduces confusion and simplifies automation integration.

Toggle Configuration

Enable CIC selectively: Reserve CIC for commands that retrieve critical configuration data. Enabling CIC on informational commands creates unnecessary alerts.

Optimize storage with Keep Unchanged Config: Enable this toggle for all commands that retrieve configuration data rather than dynamic status information. This significantly reduces storage requirements.

Configure change notifications strategically: Enable notifications only for commands where changes require attention. Too many notifications lead to alert fatigue and missed critical changes.

Comparison Optimization

Start conservative, add filters progressively: Begin with minimal comparison filtering. As you identify sources of false positives, add specific exclusions rather than enabling broad filters like “ignore whitespace” globally.

Test exclusions thoroughly: Before deploying diff exclusions to production, test them against sample configurations to ensure they filter intended content without over-matching.

Document your exclusions: Always include clear descriptions in exclusion blocks. Six months later, you’ll appreciate understanding why specific patterns were excluded.

Review exclusions periodically: As your network evolves, exclusion patterns may need updates. Review and validate exclusions quarterly or after major device upgrades.

Performance Optimization

Limit command sets size: While command sets reduce connection overhead, extremely large command sets can impact processing performance. Balance efficiency with processing load.

Use length limits judiciously: Only apply length limits when necessary for performance. Unnecessary limits may cause legitimate changes to go undetected.

Monitor comparison performance: For commands with complex exclusion patterns or large outputs, monitor comparison performance and optimize patterns as needed.

Security Considerations

Avoid storing sensitive data: Some commands may retrieve sensitive information like passwords or keys. Consider whether such commands should be included in regular backups or handled separately.

Review command permissions: Ensure that the credentials used for backups have appropriate permissions for the commands configured. Insufficient permissions cause backup failures.

Validate command safety: Before adding commands to production, verify that they don’t impact device performance or trigger any security concerns.

Troubleshooting

Common Issues and Resolutions

Commands Not Executing During Backup

Symptoms: Device backup completes but specific command outputs are missing or empty.

Possible causes:

• Command syntax incorrect for device type
• Device credentials lack permission to execute the command
• Command timeout before output fully retrieved
• Device CLI mode incorrect for command execution

Resolution steps:

1. Verify command syntax: Test the command manually on the device to confirm it executes successfully
2. Check credential permissions: Ensure the account used for backups has sufficient privileges
3. Review backup logs: Check /var/www/html/rconfig8/current/storage/logs/laravel.log for timeout errors
4. Increase timeout values: If commands take longer to execute, adjust timeout settings in device configuration
5. Verify CLI mode: Some commands require specific CLI modes (enable mode, config mode). Ensure rConfig enters the correct mode

# Check recent backup logs for errors
tail -n 100 /var/www/html/rconfig8/current/storage/logs/laravel.log | grep -i error

CIC Check Failures

Symptoms: Backups complete but CIC warnings appear for commands with CIC enabled.

Possible causes:

• Command output shorter than expected
• Command output contains error messages
• Device returned incomplete output due to session issues
• CIC enabled on informational commands that return minimal output

Resolution steps:

1. Review command output: Check the retrieved configuration file to see what was actually captured
2. Disable CIC if appropriate: If the command legitimately returns short output, disable CIC for that command
3. Investigate device issues: If output should be longer, investigate device-side issues (memory, session limits)
4. Check for error messages: Look for error messages in the command output indicating permission or syntax issues

Change Notifications Not Triggering

Symptoms: Configuration changes occur but no email notifications are received.

Possible causes:

• Change notifications toggle disabled for the command
• Email configuration not properly set up in rConfig
• Changes fall within configured exclusion patterns
• “Keep Unchanged Config” enabled and output hasn’t actually changed

Resolution steps:

1. Verify toggle state: Confirm that change notifications are enabled for the command
2. Test email configuration: Send a test email from rConfig to verify email functionality
3. Review exclusion patterns: Check if diff exclusions are filtering out the changes you expect to trigger notifications
4. Compare configs manually: Verify that the configuration actually changed between backups
5. Check notification logs: Review logs for email send attempts and failures

Diff Exclusions Not Working

Symptoms: Excluded patterns still appear in diff output or change notifications.

Possible causes:

• Regex pattern syntax errors
• Command name in scope doesn’t exactly match configured command
• Pattern doesn’t match the actual output format
• Missing or incorrect regex flags

Resolution steps:

1. Validate regex syntax: Test your regex pattern using an online regex tester with PHP flavor
2. Verify command name exact match: Ensure the command name in #[command name] exactly matches the database command, including spacing
3. Test pattern against actual output: Copy actual command output and test your pattern against it
4. Check pattern delimiters: Ensure patterns include delimiters (/pattern/) and appropriate flags
5. Review exclusion block structure: Verify the description line, scope, and pattern format follow the documented structure

// Example debugging approach
// 1. Copy the actual output line you want to exclude
// 2. Test your regex at regex101.com with PHP flavor selected
// 3. Verify the pattern matches
// 4. Add appropriate anchors (^ and $) if needed
// 5. Include any necessary flags (s, m, i)

Command Output Incomplete

Symptoms: Retrieved configuration files are shorter than expected or cut off mid-output.

Possible causes:

• Session timeout before output fully received
• Device buffer limits exceeded
• Terminal length not properly set
• Network connectivity issues during retrieval

Resolution steps:

1. Set terminal length: Many devices require terminal length 0 or equivalent to prevent pagination
2. Increase timeout values: Adjust device timeout settings if commands take longer to execute
3. Check device buffer settings: Some devices have output buffer limits that can be increased
4. Test manually: Connect to device manually and execute the command to see if pagination or truncation occurs
5. Split large commands: For commands that return massive output, consider splitting into smaller, more specific commands

Enterprise Support

For complex troubleshooting scenarios, performance optimization in large-scale deployments, or custom exclusion pattern development, enterprise support is available. Contact support for:

• Custom regex pattern development for complex exclusion scenarios
• Performance tuning for environments with thousands of commands
• Integration assistance for specialized device types
• Troubleshooting persistent command execution failures

Contact: Visit the rConfig support portal or email [email protected] for enterprise assistance.

Advanced Techniques

Dynamic Command Generation

In some scenarios, you may want to programmatically generate commands based on device inventory or network topology. While rConfig doesn’t include built-in dynamic command generation, you can use the API to create commands based on discovered device characteristics.

Use case example: Automatically create vendor-specific commands when new device types are added to inventory.

Command Output Post-Processing

For organizations with specific compliance or analysis requirements, command output can be post-processed using external scripts after retrieval. This allows for custom formatting, data extraction, or integration with third-party analysis tools.

Implementation approach: Use the Script Integration Engine (SIE) to trigger post-processing scripts after device backups complete.

Conditional Command Execution

Some commands should only execute under certain conditions (e.g., only during maintenance windows, only when specific criteria are met). While rConfig doesn’t natively support conditional execution, you can implement this using schedule-based backup policies and device tagging.

Strategy: Create separate Command Groups for conditional commands and associate them with scheduled tasks that run only during appropriate time windows.

Related Documentation

• Command Groups: Understanding how Command Groups organize devices and commands
• Device Configuration: Setting up devices for command execution
• Backup Policies: Creating scheduled backup workflows
• Script Integration Engine: Post-processing command output with custom scripts
• Change Manager: Analyzing and managing configuration changes
• Compliance Manager: Using commands for compliance verification

Quick Reference

Essential Command Configuration Steps

1. Create command with appropriate syntax
2. Assign to relevant Command Group(s)
3. Enable CIC for configuration commands
4. Enable “Keep Unchanged Config” for config commands
5. Configure change notifications selectively
6. Set comparison options as needed
7. Test command execution via device backup
8. Validate diff output and exclusions

Comparison Options At-a-Glance

Option	Purpose	Enable When	Disable When
Compare Exclusions	Filter specific patterns	Dynamic content needs filtering	All content is meaningful
Compare Context	Lines before/after changes	Need situational awareness	Want minimal diff output
Length Limit	Limit comparison size	Performance concerns	All output must be compared
Ignore Case	Treat upper/lower as same	Case doesn’t matter	Case is significant
Ignore Line Ending	Ignore CRLF vs LF	Mixed environments	Line endings matter
Ignore Whitespace	Ignore spacing differences	Formatting varies	Whitespace is meaningful

Toggle Configuration Guide

Toggle	Recommended Setting
CIC Enabled	ON for show run, show startup, config commands; OFF for informational commands
Keep Unchanged Config	ON for all configuration commands; OFF for dynamic status commands
Change Notifications	ON selectively for critical configs; OFF for routine or frequently changing commands

Exclusion Pattern Syntax Quick Reference

// Description of exclusion purpose
#[global or command name]
/regex pattern with delimiters/flags
/another pattern/flags

Common flags:

• i - Case insensitive matching
• m - Multiline mode (^ and $ match line boundaries)
• s - Dotall mode (. matches newlines)
• ms - Combined multiline and dotall (most common for multiline exclusions)

Pattern examples:

• /^! Last configuration change at .*$/ - Match timestamp line
• /^.*uptime is .*$/ - Match uptime information
• /^-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----$/ms - Match certificate block

Command Syntax Guidelines

Single command:

show running-config

Command set:

show clock
show version
show interfaces

Command with pipe:

show running-config | section interface

Requirements:

• Minimum length: 3 characters
• Maximum length: 255 characters
• Special characters and pipes supported
• Must be unique within rConfig installation

Summary

Commands form the foundation of rConfig’s configuration management capabilities. By properly configuring commands with appropriate toggles, comparison options, and exclusion patterns, organizations can achieve efficient, accurate, and actionable network configuration management.

Key Takeaways

Command configuration directly impacts storage efficiency: The “Keep Unchanged Config” toggle can reduce storage requirements by 90% or more in stable network environments by saving files only when changes occur.

Intelligent comparison prevents alert fatigue: Properly configured diff exclusions and comparison options ensure that notifications trigger only for meaningful changes, not benign variations like timestamps or uptime counters.

CIC validation ensures backup completeness: Enabling Configuration Integrity Checks on critical commands provides confidence that complete configurations are being retrieved and stored.

Multiline pattern support handles complex exclusions: The ability to exclude multi-line content like certificates and configuration blocks provides flexibility for filtering diverse device output formats.

Strategic toggle configuration optimizes operations: Understanding when to enable or disable each toggle based on command purpose ensures optimal balance between storage efficiency, change detection accuracy, and notification relevance.

Implementation Approach

Organizations implementing or optimizing commands in rConfig should follow a progressive approach:

Phase 1 - Basic setup: Create commands with standard syntax, assign to Command Groups, enable basic toggles.

Phase 2 - Optimization: Enable “Keep Unchanged Config” for appropriate commands to optimize storage.

Phase 3 - Refinement: Add comparison exclusions to filter false positive changes, configure context and other comparison options.

Phase 4 - Notification tuning: Enable change notifications selectively based on observed change patterns and organizational requirements.

Phase 5 - Continuous improvement: Review and adjust exclusion patterns, comparison options, and toggle settings based on operational experience.

This progressive approach ensures stable operation while continuously improving the accuracy and efficiency of your configuration management workflows.

Next Steps

After configuring commands, proceed to:

1. Test command execution through manual device backups
2. Review diff output to identify any false positive changes
3. Configure exclusion patterns for identified benign variations
4. Enable change notifications for critical commands
5. Monitor storage utilization and adjust “Keep Unchanged Config” settings
6. Document your command standards for consistency across teams
7. Schedule regular reviews of command configurations to ensure continued optimization

With properly configured commands, rConfig provides comprehensive, efficient, and actionable network configuration management that scales from small networks to enterprise environments with thousands of devices.