Network Configuration Integrity Checks - rConfig V8 CIC

CIC Definitions: Implementation Guide

This guide provides complete instructions for implementing Config Integrity Check definitions in rConfig V8 Pro. Critical: CIC is designed for simple, real-time completeness validation. Keep definitions simple—use basic size or line count thresholds, not complex pattern matching. CIC verifies backup completeness immediately during the backup operation; it does not analyze configuration content (use Policy Definitions for content analysis).

When to use this

Create or update CIC Definitions when your backup history shows configurations marked Invalid (no definition assigned) or when Failed backups are not triggering alerts. CIC definitions are also required for clean diff and comparison results: the Manual Compare tool and device diff views filter out Failed and Invalid configurations by default.

Prerequisites

rConfig V8 Pro installation
Devices configured and backing up successfully
Understanding that CIC checks happen in real-time during backups
Understanding the difference between CIC (completeness check) and Policy (content analysis)

Critical Concepts Before You Begin

Keep It Simple

CIC Definitions should be simple—typically 1-2 validation rules maximum. The recommended approach uses the must_match_single_string method to check for exact string matches in backed-up configurations.

Recommended approach:

Check for specific configuration lines that indicate completeness
Use exact string matching (no regex, no wildcards)
Choose lines that appear late in configurations or are mandatory sections

Not Recommended:

Complex text pattern matching
Content-based validation (that’s what Policy Definitions are for)
Multiple intricate patterns
Generic words like “end”, “exit”, “done”

Real-Time Validation

CIC validation executes immediately after each backup completes, as part of the backup operation itself. This means:

Validation happens in real-time during the backup workflow
Results are available instantly (not hours later)
Failed validations trigger immediate alerts
Remediation can happen in the same backup cycle

This differs from Policy Definitions, which run on-demand or on schedule to analyze configuration content for compliance.

CIC vs. Policy Definitions

Use CIC for: “Did we get the whole configuration?” (completeness)
Use Policy for: “Does this configuration meet standards?” (compliance)

If you’re checking for specific security settings, routing protocols, or configuration standards, you want Policy Definitions, not CIC. CIC only answers whether the backup is complete and usable.

Understanding CIC Status Values

Every backed-up configuration receives one of three CIC validation statuses based on whether CIC definitions exist and whether validation checks pass.

Status	Meaning	Operational Impact
Valid	Configuration passed all CIC checks	Safe to use for restoration, comparison, compliance
Invalid (shown as Unknown)	No CIC definition assigned, or the definition could not run	Cannot automatically verify completeness
Failed	Configuration failed CIC validation	Potentially incomplete—investigate and re-backup

Valid configurations meet all completeness criteria and can be confidently used for any operational purpose—recovery, change comparison, compliance verification, or configuration analysis.

Invalid configurations indicate missing validation rules, not backup problems. These configurations may be complete, but automatic verification isn’t possible without CIC definitions. Organizations should create CIC definitions to transition these to Valid status.

From V8.4.2, a CIC definition that can’t run also leaves the config as Unknown. This covers a missing or unreadable definition file, a block the parser can’t read, or a method CIC doesn’t support. The backup is still saved and recorded. Earlier versions failed the download instead, so the config never appeared. See Finding broken definitions to spot and fix them.

Failed configurations indicate incomplete backups requiring immediate attention. These files should not be used for restoration and require investigation to determine why validation failed and remediation to capture complete configurations.

CIC Definition File Format

CIC Definitions use a simple structured format with the must_match_single_string method for validation.

Basic Structure

// Description of what this definition validates
#[must_match_single_string]
exact_line_to_match

Components:

Description line: Required, starts with //, explains validation purpose
Method declaration: Always #[must_match_single_string] for CIC
Pattern: Exact line of text that must appear in the configuration (no regex, no wildcards)

The must_match_single_string Method

Method: must_match_single_string
Type: Exact string matching (policyString)
Description: Determines if a line in the configuration contains this exact string. Single line only! No regex supported.

How it works: rConfig searches the entire backed-up configuration for the exact text specified. If found anywhere in the configuration, validation passes. If not found, validation fails.

Simple Example

// Description: Must see Line VTY to be a completed config
#[must_match_single_string]
line vty 0 4

This definition validates that the exact line “line vty 0 4” appears somewhere in the configuration. Since VTY lines typically appear late in Cisco IOS configurations, their presence indicates the configuration was captured through to the management access section.

Creating CIC Definitions

Step 1: Identify Validation Requirements

Examine sample complete configurations to find reliable indicators of completeness. Look for:

Lines that appear late in configurations: Management access configurations (VTY lines), final interface sections, logging configuration

Mandatory configuration sections: System blocks, required services, management interfaces that must exist in any valid configuration

Vendor-specific markers: Unique configuration lines specific to complete configurations for your device vendor

What to avoid: Generic words (“end”, “exit”, “done”), common terms that appear in descriptions or remarks, words that could appear in partial configurations

Example analysis (Cisco IOS router):

Sample complete config shows:
- line con 0 (appears in middle of config)
- line vty 0 4 (appears near end of config)  ← Good choice
- end (appears in banners, descriptions, etc.)  ← Bad choice

Choose “line vty 0 4” because it’s specific, appears late in config, and won’t appear in other contexts.

Step 2: Access CIC Definition Management

Navigate to Compliance → CIC Definitions

Step 3: Create Definition

Click Add CIC Definition to open the creation form.

Form fields:

Name (required):

Descriptive name for the definition
Example: “Cisco IOS VTY Line Check”

Description (optional but recommended):

Explain what the definition validates
Note which line is being checked
Example: “Validates Cisco IOS running-config completeness by checking for VTY line configuration which appears near end of configs”

Assignment (required):

Device-specific: Assign to individual devices
Category-specific: Assign to entire device category
Select devices or categories that should use this definition

Definition Content (required):

The actual CIC definition using must_match_single_string method

Step 4: Write Definition Content

Basic Cisco IOS example:

// Description: Validate Cisco IOS completeness via VTY lines
#[must_match_single_string]
line vty 0 4

Juniper JunOS example:

// Description: Validate Juniper config has system block
#[must_match_single_string]
system {

Aruba example:

// Description: Validate Aruba config includes management section
#[must_match_single_string]
management-access {

Key principle: One simple string match is sufficient. Don’t overcomplicate CIC definitions with multiple patterns or complex matching logic.

From V8.4.2, the editor checks the definition while you type. Problems are underlined on the line they occur, and a banner above the editor lists them. Click a problem in the banner to jump to its line. Saving is refused until they’re fixed, and that includes methods CIC can’t run, such as #[evaluate_block], which only works in compliance policy definitions.

The checksum methods #[must_match_checksum] and #[must_match_any_checksum] are also for compliance policies only. A CIC definition can save them, but the rule is skipped and counts as a pass, so it never fails a backup.

Step 5: Test Definition

From V8.4.2, test a definition before you save it:

In the editor toolbar, click Test against a config (the flask icon).
Pick a device from the list. It shows the latest downloaded config for each device that runs the definition’s command; type to filter by device name.
Click Run test.

The result shows Passed, Failed or Could not run, with each rule’s result and the reason a rule failed or couldn’t run. The test uses what’s in the editor, including unsaved changes, and doesn’t change the config’s status or the definition. You need permission to view both CIC definitions and configs, and you only see configs for devices your role can access.

On earlier versions, or to confirm the result on a fresh backup, test against a real download:

Create definition
Assign to single test device
Run backup of test device
Verify configuration receives “Valid” status
Check that the exact string appears in the backed-up configuration file
If validation fails on known-complete config, choose a different validation string

If validation fails, review the actual configuration file to ensure the string you’re searching for actually appears exactly as specified (case-sensitive, spacing matters).

Rechecking Existing Configurations (V8.4.1+)

A new CIC definition only applies to backups taken after it exists. To validate configs that were already flagged, recheck them:

Selected configs: tick the configs you want in the device’s View All or Latest Good Configs list, or on the main Configs page, then click Recheck CIC on N Selected.
Whole device: click CIC Recheck on the device page.

The recheck runs in the background and the status icons update after a refresh. Configs with no matching definition stay unknown, and failed downloads are skipped. Rechecking requires the CIC definition update permission. From V8.4.2, a definition that can’t run no longer stops the recheck; the configs it covers are set to Unknown.

Pattern Examples by Vendor

Cisco IOS / IOS-XE

Recommended validation (VTY lines appear late in configs):

// Description: VTY configuration indicates complete config capture
#[must_match_single_string]
line vty 0 4

Alternative (console line if VTY numbering varies):

// Description: Console line configuration
#[must_match_single_string]
line con 0

Anti-patterns to avoid:

// DON'T USE - too generic, appears everywhere
#[must_match_single_string]
end

// DON'T USE - common word in descriptions
#[must_match_single_string]
exit

Juniper JunOS

Recommended validation:

// Description: System block must be present
#[must_match_single_string]
system {

Alternative:

// Description: Protocols section present
#[must_match_single_string]
protocols {

Aruba / HP

Recommended validation:

// Description: Management access configuration
#[must_match_single_string]
aaa authentication login privilege-mode

Fortinet FortiGate

Recommended validation:

// Description: System global section present
#[must_match_single_string]
config system global

Palo Alto

Recommended validation:

// Description: Devices section in config
#[must_match_single_string]
  <devices>

Anti-Patterns: What NOT to Use

Generic End-of-Output Words

Never use these:

end - Appears in descriptions, remarks, banners, partial configs
exit - Common command, appears throughout configs
done - Can appear in status messages, descriptions
quit - Similar issues to exit

Why these fail: A truncated backup that captures only 20% of a configuration might still contain “end” in an interface description, causing the incomplete backup to be marked Valid.

Example of false positive:

interface GigabitEthernet0/1
 description Link to backend server
 [CONNECTION DROPS HERE - INCOMPLETE BACKUP]

If you’re checking for “end”, this incomplete config might pass if “backend” contains “end” as a substring, or if any captured lines contain that word.

Generic Configuration Commands

Avoid:

hostname - Appears early, doesn’t indicate completeness
interface - Appears early and throughout config
ip address - Common throughout configs

Why: These appear early in configurations. If backup truncates after 10% capture, these lines might already be captured, incorrectly validating an incomplete backup.

Substring Matches

Remember that must_match_single_string searches for the string anywhere in a line. Be specific:

Risky:

// Too generic - "end" matches "backend", "frontend", "legend"
#[must_match_single_string]
end

Better:

// Specific line that appears late in config
#[must_match_single_string]
line vty 0 4

Advanced Pattern Techniques

Multiple Validation Strings

While typically one validation string is sufficient, you can check for multiple lines if needed for additional confidence. Give each line its own block:

// Description: Console line must be present
#[must_match_single_string]
line con 0

// Description: VTY lines must be present
#[must_match_single_string]
line vty 0 4

From V8.4.2, every rule in a definition must pass for the config to be Valid. Keep it simple, though: usually one reliable string is enough.

Command-Specific Validation

Different commands may need different validation strings:

// Description: Validate running-config completeness
#[show running-config]
#[must_match_single_string]
line vty 0 4

// Description: Validate version output completeness
#[show version]
#[must_match_single_string]
Configuration register is

Note the command-specific method blocks (#[show running-config], #[show version]). However, for CIC simplicity, usually one global validation works across commands.

Assigning CIC Definitions

Category Assignment (Recommended)

Assign CIC definitions to device categories for automatic application to all devices in that category:

Create CIC definition
In Assignment section, select Category
Choose category (e.g., “Cisco Routers”)
Save definition

Result: All devices in “Cisco Routers” category automatically use this CIC definition for backup validation.

Device Assignment

Assign CIC definitions to specific devices for exceptions or specialized validation:

Create CIC definition
In Assignment section, select Device
Choose specific devices
Save definition

Result: Selected devices use this CIC definition, overriding any category-level definitions.

Assignment Priority

When both device and category definitions exist:

Device-specific definition takes precedence
Category definition applies if no device-specific definition exists
No definition results in “Invalid” status

Monitoring CIC Validation Results

Device Configuration History

View CIC status for all backed-up configurations:

Navigate to Devices → [Device Name] → Config History
Each configuration shows CIC status (Valid/Invalid/Failed)
Click configuration to view validation details

Configuration Reports

Configuration Reports include CIC validation status, showing which backups passed or failed validation across all scheduled tasks.

Finding broken definitions

From V8.4.2, rConfig flags a CIC definition that has problems in its file or that couldn’t run during a backup:

CIC Definitions list: a warning icon appears next to the definition’s name. Hover over it for a summary; click it to open the definition.
Definition editor: a banner shows when the definition last failed to run, on which device, and why, along with any problems in the file. Definitions saved before V8.4.1, or edited directly on disk, can be flagged here before they ever run.
Settings → Application Logs: filter Event type by cic to see each failure, with the definition and device named. The filter matches part of the name, so cic also shows cic_recheck entries.

Fix the definition and save it. The warning clears the next time the definition runs cleanly against a backup.

Failed Validation Alerts

rConfig sends an email notification automatically when a CIC re-check job fails. Notifications go to the system email address set by MAIL_FROM_ADDRESS in your .env file. No additional UI configuration is required — ensure your mail settings are correctly configured for delivery.

Disabling CIC Checks

In some scenarios, CIC validation may need to be temporarily disabled—during initial rollout, for devices with non-standard configurations, or for troubleshooting purposes.

Per-Command Disable

CIC validation is toggled at the individual command level, not globally. To disable CIC for a specific backup command:

Navigate to the device’s command list (select the device, then open the Commands tab)
Find the command and click the CIC toggle button to switch it Off

Result: That command’s backups will no longer run CIC validation. All new backups from that command receive “Invalid” status until the toggle is re-enabled.

Troubleshooting CIC Validation

All Backups Showing “Failed”

Symptom: Every backup for a category or device shows “Failed” status.

Possible causes:

CIC definition string doesn’t match actual device output
String is case-sensitive and doesn’t match exactly
Device output format changed (OS version upgrade)

Resolution:

Review sample configuration files to verify string matches exactly
Check case sensitivity and spacing
Test string against known-complete configs
Choose a different validation string that reliably appears

Intermittent “Failed” Status

Symptom: Same device sometimes shows “Valid”, sometimes “Failed”.

Possible causes:

Network instability causing occasional incomplete backups
Device resource constraints causing timeouts
Connection timeout settings too aggressive

Resolution:

Review backup logs for timeout or connection errors
Increase connection timeout in device settings
Investigate network path stability
Check device CPU/memory during backup operations

Configs Showing “Failed” After Upgrading to V8.4.2

Symptom: Configs that were Valid before the upgrade now show “Failed”, and the definition has more than one rule.

Cause: From V8.4.2, every rule must pass. Before, only the last rule counted.

Resolution:

Use Test against a config to see which rule fails
Fix or remove that rule, or capture a complete backup
Run CIC Recheck to update existing configs

“Invalid” Status After Creating Definition

Symptom: Created CIC definition but devices still show “Invalid”.

Possible causes:

Definition not assigned to devices or category
Definition disabled
Device-specific disable overriding definition

Resolution:

Verify definition assignment in definition settings
Confirm definition is enabled
Check device settings for CIC disable flag
Re-run backup to apply new definition

Definition Not Matching Expected String

Symptom: Known-complete configurations failing validation.

Possible causes:

String doesn’t appear exactly as specified in config
Case sensitivity issue (capital vs lowercase)
Extra spaces or different spacing than expected

Resolution:

Open actual configuration file and search for the exact string
Verify case matches exactly
Check for extra spaces or tabs
Choose a different, more reliable validation string

Best Practices

Start Simple

Begin with basic single-string validation, then add complexity only if needed:

Phase 1: Single validation string (e.g., VTY line)
Phase 2: Test across multiple devices
Phase 3: Deploy to production
Phase 4: Only add additional patterns if single string proves insufficient

Test Before Production

Never deploy untested CIC definitions to production:

Create definition
Assign to test device or small test category
Run multiple backups to verify consistent validation
Review failed validations to identify pattern issues
Refine and retest
Deploy to production after confirming reliable validation

Document Patterns

Include clear descriptions in CIC definitions explaining:

What string is being validated
Why this string indicates completeness
Any device-specific considerations
Last testing date and verified OS versions

Monitor Failed Validations

Establish regular monitoring of CIC failures:

Daily review of failed validations
Trending analysis (increasing failures indicate problems)
Investigation workflow for persistent failures
Remediation tracking

Maintain Definitions

Review CIC definitions quarterly:

Test against current device OS versions
Verify strings still appear in device output
Update strings if device output format changed
Validate that patterns still reliably indicate completeness

Common Validation Patterns

Lines That Appear Late in Configs

Cisco IOS: line vty 0 4, line con 0
Juniper: Final configuration block closures
Aruba: Management access configuration sections

Mandatory Configuration Sections

Cisco IOS: VTY lines (always present for management)
Juniper: system { (mandatory system block)
Palo Alto: Device XML structure tags

Avoid These Patterns

Never use: end, exit, done, quit, hostname, interface

Why: Too generic, appear in multiple contexts, don’t reliably indicate completeness

Video Tutorials

For visual walkthroughs of CIC definition creation and management, see rConfig’s YouTube channel:

rConfig CIC Definition Tutorials

Config Integrity Check Concepts - Understanding why and when to use CIC
Policy Development Workflow - Definition file format, testing, and deployment
Configuration Backup Implementation - Backup operations overview
Configuration Reports - Monitoring CIC validation results

Quick Reference

CIC Status Summary

Status	Meaning	Action Required
Valid	Passed validation	None - backup is complete
Invalid (Unknown)	No definition, or the definition could not run	Create a CIC definition, or fix the flagged one
Failed	Failed validation	Investigate and re-backup

Basic Definition Template

// Description of validation
#[must_match_single_string]
exact_string_to_match

Assignment Methods

Category: Applies to all devices in category
Device: Applies to specific devices only
Priority: Device assignment overrides category assignment

Key Principles

Keep it simple - one validation string is usually sufficient
Use exact string matching - no regex
Choose strings that appear late in configs or are mandatory
Avoid generic words like “end”, “exit”, “done”
Test before production deployment

Network Configuration Integrity Checks - rConfig V8 CIC

CIC Definitions: Implementation Guide

When to use this

Prerequisites

Critical Concepts Before You Begin

Keep It Simple

Real-Time Validation

CIC vs. Policy Definitions

Understanding CIC Status Values

CIC Definition File Format

Basic Structure

The must_match_single_string Method

Simple Example

Creating CIC Definitions

Step 1: Identify Validation Requirements

Step 2: Access CIC Definition Management

Step 3: Create Definition

Step 4: Write Definition Content

Step 5: Test Definition

Rechecking Existing Configurations (V8.4.1+)

Pattern Examples by Vendor

Cisco IOS / IOS-XE

Juniper JunOS

Aruba / HP

Fortinet FortiGate

Palo Alto

Anti-Patterns: What NOT to Use

Generic End-of-Output Words

Generic Configuration Commands

Substring Matches

Advanced Pattern Techniques

Multiple Validation Strings

Command-Specific Validation

Assigning CIC Definitions

Category Assignment (Recommended)

Device Assignment

Assignment Priority

Monitoring CIC Validation Results

Device Configuration History

Configuration Reports

Finding broken definitions

Failed Validation Alerts

Disabling CIC Checks

Per-Command Disable

Troubleshooting CIC Validation

All Backups Showing “Failed”

Intermittent “Failed” Status

Configs Showing “Failed” After Upgrading to V8.4.2

“Invalid” Status After Creating Definition

Definition Not Matching Expected String

Best Practices

Start Simple

Test Before Production

Document Patterns

Monitor Failed Validations

Maintain Definitions

Common Validation Patterns

Lines That Appear Late in Configs

Mandatory Configuration Sections

Avoid These Patterns

Video Tutorials

Related Documentation

Quick Reference

CIC Status Summary

Basic Definition Template

Assignment Methods

Key Principles