Network Configuration Integrity Checks - rConfig V8 CIC

Note

CIC (Config Integrity Check) was formerly known as EOC (End of Config). While ‘CIC’ is now the primary terminology, you may still encounter ‘EOC’ references in URLs, permission tables, and legacy documentation.

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).

---

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	No CIC definition assigned	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.

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.

Note

For complete format documentation including advanced features, see the CIC Definition File Format Guide.

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 Settings → CIC → 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.

Step 5: Test Definition

Before deploying to production, test CIC definitions against known-complete configuration files:

1. Create definition
2. Assign to single test device
3. Run backup of test device
4. Verify configuration receives “Valid” status
5. Check that the exact string appears in the backed-up configuration file
6. 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).

---

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:

// Description: Check for both VTY and console lines
#[must_match_single_string]
line con 0
line vty 0 4

Both lines must be present for validation to pass. However, keep it simple—usually one reliable string is sufficient.

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:

1. Create CIC definition
2. In Assignment section, select Category
3. Choose category (e.g., “Cisco Routers”)
4. 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:

1. Create CIC definition
2. In Assignment section, select Device
3. Choose specific devices
4. 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:

1. Navigate to Devices → [Device Name] → Config History
2. Each configuration shows CIC status (Valid/Invalid/Failed)
3. 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.

Failed Validation Alerts

Configure email notifications for CIC validation failures:

1. Navigate to Settings → Notifications
2. Enable “CIC Validation Failure” notifications
3. Configure recipients

Operations teams receive immediate notification when backups fail validation.

---

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.

Global Disable

Disable CIC validation system-wide:

1. Navigate to Settings → CIC → CIC Settings
2. Toggle Enable CIC Validation to Off
3. Save changes

Result: No configurations are validated. All backups receive “Invalid” status.

---

Troubleshooting CIC Validation

All Backups Showing “Failed”

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

Possible causes:

1. CIC definition string doesn’t match actual device output
2. String is case-sensitive and doesn’t match exactly
3. 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:

1. Network instability causing occasional incomplete backups
2. Device resource constraints causing timeouts
3. 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

”Invalid” Status After Creating Definition

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

Possible causes:

1. Definition not assigned to devices or category
2. Definition disabled
3. 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:

1. String doesn’t appear exactly as specified in config
2. Case sensitivity issue (capital vs lowercase)
3. 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:

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

Test Before Production

Never deploy untested CIC definitions to production:

1. Create definition
2. Assign to test device or small test category
3. Run multiple backups to verify consistent validation
4. Review failed validations to identify pattern issues
5. Refine and retest
6. 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

---

Related Documentation

• Config Integrity Check Concepts - Understanding why and when to use CIC
• CIC Definition File Format - Complete format specification
• 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	No definition	Create CIC definition
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

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