Policy Definitions

Policy Definitions: Creating Network Configuration Compliance Rules in rConfig V8 Pro

Policy Definitions contain the compliance rules that rConfig uses to validate device configurations. A policy definition is a text-based file using a simplified format that specifies what configuration elements to validate and how to validate them. Multiple policy assignments can use the same definition, making policies reusable across your network infrastructure.

This guide focuses on creating policy definitions, understanding the definition structure, and building policy content using rConfig’s 14 validation methods. For testing and development workflows, see the Policy Development and Testing Workflow documentation.

Understanding Policy Definitions

What Policy Definitions Are

A policy definition is a collection of one or more rule blocks, each evaluating a specific aspect of device configuration. Each rule block consists of:

A comment describing what the rule validates
A policy method specifying how to validate
One or more configuration lines to evaluate

Policy definitions are written in a human-readable text format, making them easy to create, modify, and maintain. Unlike complex scripting languages, the format is intuitive and self-documenting when proper comments are used.

Why Policy Definitions Matter

Reusability: A single policy definition can be applied to hundreds or thousands of devices through policy assignments, eliminating the need to configure rules repeatedly.

Consistency: Centralized policy definitions ensure all devices in a scope are evaluated against identical rules, preventing configuration drift across the network.

Maintainability: Text-based format with comments makes policies easy to understand and modify. Updates to a definition automatically apply to all assignments using that definition.

Version control: Policy definitions can be exported, versioned in external systems like Git, and imported into other rConfig instances, enabling policy standardization across multiple installations.

Flexibility: With 14 different validation methods supporting exact matching, wildcards, regex patterns, and code block matching, policy definitions accommodate any compliance requirement.

Accessing Policy Definitions

Navigate to Compliance → Policy Definitions to access the policy definition management interface.

Policy Definitions Main View

Main view displays:

Policy definition name and description
Creation and last modified dates
Number of assignments using each definition
Actions: View/Edit, Peek (quick view), Delete

Expandable details: Click the expand icon to view:

Full policy definition content
List of assignments using this definition
Quick access to edit or peek at policy content

Creating a Policy Definition

Step 1: Add New Definition

Click New Policy Definition button to create a new policy.

Initial configuration:

Enter Name: Descriptive, unique identifier (e.g., “Security-Baseline-Cisco-IOS”)
Enter Description (optional): Detailed explanation of policy purpose and scope
Click Create

The policy editor loads with a default template providing structure examples.

Policy Definition Editor

Step 2: Access Policy Definition Help

Before writing your first policy, access the comprehensive in-app help.

To access help:

Click Policy Definition Help button in the editor
Help dialog displays all 14 policy methods with syntax and examples
Keep help open in separate window while writing policies

Policy Definition Help Dialog

The help dialog provides:

Complete method reference with descriptions
Syntax examples for each method
Wildcard usage guidelines
Best practices for policy structure

Step 3: Write Policy Rules

Build your policy by adding rule blocks following the standard structure.

Policy Definition Structure

Basic Format

Every rule block follows this three-part structure:

// Description: [Comment explaining what this rule validates]
#[policy_method]
configuration line(s) to evaluate

Structure requirements:

Comment line starts with // (required for documentation)
Policy method wrapped in #[brackets] (case-sensitive)
Configuration lines follow method (quantity depends on method type)
Empty line between rule blocks (recommended for readability)

Complete Example

// Description: Verify NTP server is configured
#[must_match_single_string]
ntp server 192.168.1.10

// Description: Ensure SSH version 2 is enabled
#[must_match_single_string]
ip ssh version 2

// Description: Confirm no Telnet server
#[must_not_match_single_string]
transport input telnet

// Description: Validate logging to syslog server
#[must_match_single_string]
logging host 192.168.1.100

Multi-Block Policies

Combine multiple rule blocks in a single definition to validate related configuration elements:

// Description: Verify primary NTP server
#[must_match_single_string]
ntp server 192.168.1.10

// Description: Verify secondary NTP server
#[must_match_single_string]
ntp server 192.168.1.11

// Description: Ensure timezone is set correctly
#[must_match_single_string]
clock timezone EST -5 0

// Description: Confirm no insecure NTP authentication
#[must_not_match_single_string]
ntp authenticate

All rules must pass: For a device to pass compliance, ALL rule blocks in the definition must evaluate successfully. If any single rule fails, overall result is FAIL.

Policy Methods Overview

rConfig V8 provides 14 policy methods organized into three categories:

String Methods (Single Line)

Exact matching:

must_match_single_string - Must contain exact string
must_not_match_single_string - Must NOT contain exact string

Regex pattern matching:

must_match_regex - Must match regex pattern
must_not_match_regex - Must NOT match regex pattern

Wildcard matching:

wildcard_match_single_string - Match with * and ? wildcards
wildcard_must_not_match_single_string - Must NOT match wildcard pattern

Array Methods (Multiple Lines)

Any match:

can_match_any_from_array - Pass if ANY line matches
wildcard_match_any_from_array - ANY match with wildcards

All match:

must_match_all_from_array - Pass only if ALL lines match
wildcard_match_all_from_array - ALL match with wildcards
must_not_match_all_from_array - Pass only if ALL lines DON’T match

Code Block Methods (Sequential/Flexible)

Sequential matching:

match_code_block_from_array - Match sequential code blocks

Flexible matching:

match_code_block_flexible - Order-agnostic block matching

Building Policy Content

Choosing the Right Method

Select policy methods based on what you’re validating:

Use exact string methods when:

Validating specific configuration lines that never vary
Checking for presence or absence of exact commands
Configuration elements have no acceptable variations

Use wildcard methods when:

Configuration values have predictable variations (IP addresses, interface numbers)
Need flexibility in matching while maintaining specificity
Avoiding false positives from minor formatting differences

Use regex methods when:

Complex pattern matching required
Multiple acceptable formats exist for same configuration
Need conditional validation (must NOT exist when parent doesn’t exist)

Use array methods when:

Validating multiple related configuration lines
Any one of several alternatives is acceptable (ANY)
All lines must be present simultaneously (ALL)

Use code block methods when:

Validating configuration sections (interfaces, ACLs, routing protocols)
Order of lines within block matters (sequential)
Order doesn’t matter but logical grouping does (flexible)

String Method Examples

must_match_single_string

Exact string match required. Case-sensitive, no wildcards, single line only.

// Description: Verify specific NTP server configured
#[must_match_single_string]
ntp server 192.168.1.10 prefer

Validation: Configuration must contain this exact line to pass.

must_not_match_single_string

Exact string must NOT exist. Use for prohibited configurations.

// Description: Ensure no default SNMP community
#[must_not_match_single_string]
snmp-server community public

Validation: If this line exists in configuration, rule fails.

wildcard_match_single_string

Match with wildcards for flexible validation.

Wildcard syntax:

* = Match 0 or more characters (lazy)
? = Match exactly 1 character

// Description: Match any GigabitEthernet interface
#[wildcard_match_single_string]
interface GigabitEthernet?/?

// Description: Match any SNMP server with any community
#[wildcard_match_single_string]
snmp-server host *.*.*.* *

Validation: Pattern must match at least one configuration line.

must_match_regex

Use regular expressions for complex pattern matching.

// Description: Match multiline content with letters and numbers
#[must_match_regex]
"/\\bMixed content with letters and numbers: [a-zA-Z0-9]+/gm"

Important notes:

Wrap regex in double quotes
Use regex flags: /g (global), /m (multiline), /i (case-insensitive)
Test regex at regex101.com before using in policies
Escape special characters appropriately

must_not_match_regex

Conditional validation—rule passes when pattern does NOT exist.

// Description: Ensure fast-forward not enabled when no bridges exist
#[must_not_match_regex]
"/interface bridge.*fast-forward=yes/m"

Use case: Prevents false positives when validating security settings that should only apply if parent feature exists.

Array Method Examples

can_match_any_from_array

Pass if ANY line from array matches. Use for alternative acceptable values.

// Description: Match any approved NTP server
#[can_match_any_from_array]
ntp server 192.168.1.10
ntp server 192.168.1.11
ntp server 10.10.1.10

Validation: At least one of these lines must exist. Others are optional.

must_match_all_from_array

Pass only if ALL lines from array match. Use when all elements required.

// Description: All required SNMP configurations must exist
#[must_match_all_from_array]
snmp-server host 192.168.1.10 community-string
snmp-server contact [email protected]
snmp-server location "Data Center A"

Validation: Every line must exist in configuration for rule to pass.

wildcard_match_all_from_array

ALL lines must match, with wildcard support.

// Description: Validate all DNS servers with wildcard community
#[wildcard_match_all_from_array]
ip name-server 8.8.8.8
ip name-server 8.8.4.4
snmp-server community *READ*

Validation: All patterns must match, wildcards add flexibility to matching.

must_not_match_all_from_array

Pass only if ALL lines DON’T match (none should exist).

// Description: Ensure no insecure protocols enabled
#[must_not_match_all_from_array]
service telnet
ip http server
no ip domain-lookup

Validation: None of these lines should exist. If any exist, rule fails.

Code Block Method Examples

match_code_block_from_array

Match sequential code blocks. Lines must appear in order.

// Description: Validate interface configuration block
#[match_code_block_from_array]
interface GigabitEthernet0/1
 description Uplink to Core
 ip address 192.168.1.1 255.255.255.0
 no shutdown

Validation: Finds first line, then verifies subsequent lines appear sequentially in configuration block.

Use for: Interface configs, ACLs, route-maps, any sequential configuration blocks.

match_code_block_flexible

Flexible, order-agnostic matching within logical blocks.

// Description: Validate LLDP configuration (order doesn't matter)
#[match_code_block_flexible]
protocols {
    lldp {
        management-address *;
        interface all {
            enable;

Key features:

Finds configuration block using first pattern
Searches for all other patterns within that block
Order doesn’t matter
Automatically skips comments and empty lines

Use for: Protocol configs (OSPF, BGP, LLDP), where order varies but logical grouping matters.

Policy Definition Best Practices

Comments and Documentation

Always include descriptive comments: Every rule block requires a comment explaining what it validates and why.

Good comment example:

// Description: Verify SSH version 2 for PCI-DSS compliance requirement 2.3
#[must_match_single_string]
ip ssh version 2

Poor comment example:

// Check SSH
#[must_match_single_string]
ip ssh version 2

Comment guidelines:

Explain what is being validated
Include reasoning when relevant (compliance standard, security requirement)
Reference ticket numbers or change requests if applicable
Document any exceptions or special cases

Structure and Formatting

Use empty lines between blocks: Improves readability and maintainability.

// Description: First rule
#[must_match_single_string]
configuration line

// Description: Second rule
#[must_match_single_string]
another configuration line

Group related rules: Keep logically related rules together in the definition.

// NTP Configuration Section
// Description: Primary NTP server
#[must_match_single_string]
ntp server 192.168.1.10

// Description: Secondary NTP server
#[must_match_single_string]
ntp server 192.168.1.11

// SNMP Configuration Section
// Description: SNMP community string
#[must_match_single_string]
snmp-server community secure-community

Method Selection

Start with simple methods: Use must_match_single_string and must_not_match_single_string first. Add complexity only when needed.

Use wildcards for flexibility: When configuration elements vary predictably (interface numbers, IP octets), wildcards prevent false failures.

Avoid over-complicated regex: Complex regex patterns are hard to maintain and troubleshoot. If regex becomes too complex, consider multiple simpler rules.

Test code block methods carefully: Sequential and flexible block matching can have unexpected behavior. Test thoroughly against representative configurations.

Naming Conventions

Use descriptive definition names:

Security-Baseline-Cisco-IOS
NTP-Standard-All-Devices
PCI-DSS-Firewall-Requirements

Avoid generic names:

Policy1
Test
New-Definition

Include scope indicators:

Device type: Cisco-IOS, Juniper-JUNOS
Purpose: Security, Standards, Compliance
Audience: Production, Lab, DMZ

Testing Before Deployment

Test against known-good configurations: Verify policy passes on devices you know are compliant.

Test against known-bad configurations: Verify policy fails on devices with non-compliant configurations.

Use disabled assignments for testing: Create test assignments targeting small device groups with assignment disabled. Enable only after validation.

Iterate and refine: Start with basic rules, validate, then expand. Don’t try to create comprehensive policies in one pass.

See Policy Development and Testing Workflow for detailed testing procedures.

Managing Policy Definitions

Viewing Definitions

Main view: Lists all policy definitions with summary information.

Expand view: Click expand icon to see:

Full policy content preview
Assignments using this definition
Edit/Delete actions

Peek function: Quick view of policy content without opening full editor.

Editing Definitions

Click Edit to modify existing policy definition.

Edit considerations:

Changes apply to ALL assignments using this definition
Test changes before saving in production environments
Consider creating new version instead of modifying widely-used definitions
Document significant changes in external version control

Deleting Definitions

Delete unused or obsolete policy definitions.

Before deleting:

Verify no active assignments use the definition
Export definition for archival if might be needed later
Document reason for deletion

Cannot delete if: Any policy assignments reference the definition. Delete or reassign those assignments first.

Exporting and Importing Definitions

Export use cases:

Backup definitions before major changes
Share definitions between rConfig instances
Version control in external systems (Git)
Contribute to rConfig policy template repository

Import use cases:

Load definitions from GitHub template repository
Transfer policies between rConfig installations
Restore definitions from backups
Adopt community-contributed policies

GitHub Policy Repository: rConfig maintains a public repository of policy definition templates for common compliance scenarios. Import these directly through the UI or contribute your own tested policies for community benefit.

Common Policy Definition Patterns

Security Baseline

// Description: Enable secret password configured
#[must_match_single_string]
enable secret 5

// Description: SSH version 2 enabled
#[must_match_single_string]
ip ssh version 2

// Description: Telnet disabled
#[must_not_match_single_string]
transport input telnet

// Description: AAA authentication enabled
#[must_match_single_string]
aaa new-model

Standard Services

// Description: NTP servers configured
#[must_match_all_from_array]
ntp server 192.168.1.10
ntp server 192.168.1.11

// Description: DNS servers configured
#[must_match_all_from_array]
ip name-server 8.8.8.8
ip name-server 8.8.4.4

// Description: Syslog server configured
#[must_match_single_string]
logging host 192.168.1.100

Interface Standards

// Description: All interfaces must have descriptions
#[must_match_regex]
"/interface .+\\n\\s+description/gm"

// Description: No shutdown on uplink interfaces
#[wildcard_match_single_string]
interface GigabitEthernet0/?
 no shutdown

Prohibited Configurations

// Description: No default SNMP communities
#[must_not_match_all_from_array]
snmp-server community public
snmp-server community private

// Description: No IP HTTP server
#[must_not_match_single_string]
ip http server

// Description: No insecure protocols
#[must_not_match_all_from_array]
service telnet
service finger

Troubleshooting Policy Definitions

Syntax Validation Errors

Symptom: Cannot save policy definition, syntax error displayed.

Common causes:

Missing // before comment
Incorrect method name or case
Missing #[brackets] around method
Extra characters in method name

Resolution: Review syntax carefully against examples in Policy Definition Help dialog.

Policy Always Fails

Symptom: All devices fail policy even though configurations appear correct.

Diagnosis:

Check for case sensitivity issues in configuration lines
Verify extra/missing whitespace in policy strings
Confirm configuration lines match exact device output format
Test with wildcard_match_single_string to identify matching issues

Resolution: Copy exact configuration line from device output into policy definition.

Policy Never Fails

Symptom: All devices pass policy even when configurations are known to be non-compliant.

Diagnosis:

Verify policy method is appropriate for validation type
Check that configuration command specified in assignment matches where config exists
Confirm devices have recent configuration files downloaded
Test policy against known-bad configuration manually

Resolution: Review method selection and assignment configuration.

Regex Pattern Not Matching

Symptom: Regex-based rules fail unexpectedly.

Diagnosis:

Test regex pattern at regex101.com with actual device output
Verify regex flags are correct (/g, /m, /i)
Check for unescaped special characters
Confirm quotes wrap entire regex pattern

Resolution: Refine regex pattern using external testing tool before implementing in policy.

Compliance Overview - Understanding the compliance system architecture
Policy Assignments - Linking policies to devices
Policy Development and Testing Workflow - Testing and validating policies
Policy Compliance Results - Reviewing compliance reports

Quick Reference

Policy Definition Structure

// Description: [What this validates]
#[policy_method]
configuration line(s)

All Policy Methods

Method	Type	Use Case
must_match_single_string	String	Exact string must exist
must_not_match_single_string	String	Exact string must NOT exist
must_match_regex	String	Regex pattern must match
must_not_match_regex	String	Regex pattern must NOT match
wildcard_match_single_string	String	Wildcard pattern must match
wildcard_must_not_match_single_string	String	Wildcard must NOT match
can_match_any_from_array	Array	ANY line must match
must_match_all_from_array	Array	ALL lines must match
must_not_match_all_from_array	Array	NO lines should match
wildcard_match_any_from_array	Array	ANY with wildcards
wildcard_match_all_from_array	Array	ALL with wildcards
match_code_block_from_array	Block	Sequential block matching
match_code_block_flexible	Block	Flexible block matching

Wildcard Syntax

* = 0 or more characters (lazy match)
? = Exactly 1 character

Best Practices Checklist

Summary

Policy Definitions are the foundation of rConfig’s compliance system, containing the rules that validate device configurations against organizational standards. The text-based definition format with 14 validation methods provides flexibility to accommodate any compliance requirement while remaining human-readable and maintainable.

Key Takeaways

Simple yet powerful format: Text-based structure with comments, methods, and configuration lines makes policies easy to create and understand while supporting complex validation scenarios.

14 validation methods: From simple exact string matching to flexible code block matching, the method library accommodates any compliance requirement without scripting complexity.

Reusable across assignments: Single definitions apply to multiple device scopes through assignments, ensuring consistency and simplifying maintenance.

Well-documented is well-maintained: Comprehensive comments in policies ensure future administrators understand validation logic and can confidently modify rules as requirements evolve.

Test before deploying: Use the development and testing workflow to validate policies against representative configurations before production deployment, preventing widespread false failures.

With properly structured policy definitions using appropriate validation methods and comprehensive comments, rConfig provides reliable, scalable compliance enforcement across your entire network infrastructure.

Policy Definitions

Policy Definitions: Creating Network Configuration Compliance Rules in rConfig V8 Pro

Understanding Policy Definitions

What Policy Definitions Are

Why Policy Definitions Matter

Accessing Policy Definitions

Creating a Policy Definition

Step 1: Add New Definition

Step 2: Access Policy Definition Help

Step 3: Write Policy Rules

Policy Definition Structure

Basic Format

Complete Example

Multi-Block Policies

Policy Methods Overview

String Methods (Single Line)

Array Methods (Multiple Lines)

Code Block Methods (Sequential/Flexible)

Building Policy Content

Choosing the Right Method

String Method Examples

must_match_single_string

must_not_match_single_string

wildcard_match_single_string

must_match_regex

must_not_match_regex

Array Method Examples

can_match_any_from_array

must_match_all_from_array

wildcard_match_all_from_array

must_not_match_all_from_array

Code Block Method Examples

match_code_block_from_array

match_code_block_flexible

Policy Definition Best Practices

Comments and Documentation

Structure and Formatting

Method Selection

Naming Conventions

Testing Before Deployment

Managing Policy Definitions

Viewing Definitions

Editing Definitions

Deleting Definitions

Exporting and Importing Definitions

Common Policy Definition Patterns

Security Baseline

Standard Services

Interface Standards

Prohibited Configurations

Troubleshooting Policy Definitions

Syntax Validation Errors

Policy Always Fails

Policy Never Fails

Regex Pattern Not Matching

Related Documentation

Quick Reference

Policy Definition Structure

All Policy Methods

Wildcard Syntax

Best Practices Checklist

Summary

Key Takeaways