Policy Definition File Format

Policy Definition File Format: Syntax and Validation Methods for Network Configuration Compliance

Policy definitions in rConfig V8 use a streamlined format that simplifies policy creation while maintaining powerful compliance evaluation capabilities. This addresses the challenge of writing complex compliance rules by using an intuitive comment-and-annotation structure that improves readability, reduces errors, and accelerates policy development.

Organizations can leverage this simplified format to create compliance policies efficiently, maintain policy libraries effectively, and enable broader team participation in compliance management without requiring deep technical expertise in regular expressions or complex syntax.

Understanding the Policy Definition Format

Format Structure

Policy definitions use a comment-and-annotation format that clearly separates policy description, evaluation method, and pattern matching:

// Description: must_match_single_string SNMP Policy
#[must_match_single_string]
snmp-server host 1.1.1.1 TESTCOMMUNITY

This structure provides three distinct elements:

Comment line: Describes the policy purpose and evaluation method
Method annotation: Specifies which evaluation method to use (enclosed in #[...])
Pattern specification: The configuration pattern to evaluate

Format Benefits

Simplified syntax: The streamlined format eliminates complex JSON structures, quotation mark escaping, and structural complexity. Policy authors focus on compliance requirements rather than syntax correctness.

Improved readability: Human-readable comments and clear method annotations make policies self-documenting. Reviewing policies becomes straightforward even for team members unfamiliar with their creation.

Reduced errors: Simpler syntax reduces formatting mistakes, bracket mismatches, and escaping errors. The editor provides syntax validation and auto-completion reducing common mistakes.

Faster development: Policy creation accelerates with auto-complete for method annotations, inline documentation, and cleaner structure. Experienced users report significantly faster policy development.

Better maintainability: Clear structure and separation of concerns simplifies policy updates. Modifying patterns or methods requires minimal syntax adjustment.

Team accessibility: Non-developer team members can read and understand policies more easily, enabling broader participation in compliance program development and review.

Format Rules and Syntax

Basic Format Rules

Policy definitions follow a structured block format with specific rules:

Rule 1: Block separation: Policy blocks must be separated by blank lines. Each blank line indicates the start of a new policy evaluation.

// First policy block
#[must_match_single_string]
policy pattern one

// Second policy block - note blank line above
#[must_match_single_string]
policy pattern two

Rule 2: Comment-first structure: Each block must begin with a comment describing the policy purpose and evaluation method.

// Description: must_match_single_string Disable HTTP Server

The comment serves as documentation and appears in compliance reports when policies fail, helping operations teams understand policy intent.

Rule 3: Method annotation: Following the comment, specify the evaluation method using annotation syntax enclosed in square brackets prefaced by a hash symbol.

#[must_match_single_string]

Available method annotations correspond to the evaluation methods rConfig supports. Auto-complete in the editor displays all available methods when typing #[.

Rule 4: Pattern specification: The line following the method annotation contains the pattern that will be evaluated against device configurations.

no ip http server

Pattern format depends on the evaluation method: string literals, comma-separated arrays, or regular expressions.

Wildcard Syntax

rConfig supports wildcard characters for flexible pattern matching:

Asterisk (*): Matches zero or more characters (lazy matching). Internally converted to regex .*? pattern.

Question mark (?): Matches exactly one single character. Internally converted to regex . pattern.

Wildcard examples:

snmp-server host *.1.?.? TESTCOMMUNITY10 matches snmp-server host 192.168.1.1 TESTCOMMUNITY10
interface *test* matches interface GigabitEthernet0/0/0-test-lab
aaa session-* matches aaa session-id common or aaa session-id unique

Policy Evaluation Methods

String Matching Methods

must_match_single_string

Type: policyString

Description: Configuration must contain the exact specified string.

Example:

// Description: must_match_single_string Disable CDP
#[must_match_single_string]
no cdp run

Use cases: Verifying specific configuration commands exist, checking for security hardening configurations, validating standard organizational settings.

must_not_match_single_string

Type: policyString

Description: Configuration must NOT contain the specified string.

Example:

// Description: must_not_match_single_string Ensure HTTP Server Disabled
#[must_not_match_single_string]
ip http server

Use cases: Ensuring deprecated or insecure commands are absent, verifying protocols are disabled, checking that test configurations are not present.

must_include_substring

Type: policyString

Description: Configuration must contain the substring anywhere within lines.

Example:

// Description: must_include_substring Password Encryption Enabled
#[must_include_substring]
password-encryption

Use cases: Checking for configuration elements where exact line format varies, verifying partial configuration strings regardless of surrounding text.

must_not_include_substring

Type: policyString

Description: Configuration must NOT contain the substring anywhere.

Example:

// Description: must_not_include_substring No Telnet Configuration
#[must_not_include_substring]
telnet

Use cases: Ensuring legacy protocols are completely absent, verifying insecure methods are not configured anywhere in the device.

Wildcard Matching Methods

wildcard_match_single_string

Type: policyString

Description: Determine if configuration contains a pattern with wildcard support. Asterisks (*) match zero or more characters, question marks (?) match exactly one character. Passes compliance on any matches.

Example:

// Description: Wildcard match single string
#[wildcard_match_single_string]
snmp-server host *.1.?.? TESTCOMMUNITY10

Use cases: Matching configuration patterns with variable IP addresses, interface numbers, or hostnames where exact values vary but structure remains consistent.

wildcard_match_any_from_array

Type: policyArray

Description: Matches if configuration contains any wildcard pattern from the provided array. Supports asterisk and question mark wildcards in each array element.

Example:

// Description: Wildcard match any configurations from array
#[wildcard_match_any_from_array]
snmp-server host 1.1.1.1 TESTCOMMUNITY*, snmp-server host 1.1.?.? TESTCOMMUNITY30, aaa session-*

Use cases: Checking for multiple acceptable configuration variations, validating that at least one of several patterns exists regardless of specific values.

wildcard_must_not_match_single_string

Type: policyString

Description: Determine if a wildcard pattern does NOT exist in the configuration. Returns true when the pattern is absent. Ideal for ensuring test or temporary configurations are not present in production environments. Supports asterisk and question mark wildcards.

Example:

// Description: Ensure no test interfaces exist in production
#[wildcard_must_not_match_single_string]
interface *test*

Use cases: Preventing test configurations in production, ensuring temporary or development settings are removed, validating naming conventions exclude specific patterns.

Array Matching Methods

must_match_all_from_array

Type: policyArray

Description: Configuration must contain all items from the comma-separated list. All elements must be present for policy to pass.

Example:

// Description: must_match_all_from_array AAA Authentication
#[must_match_all_from_array]
aaa authentication login default local, aaa authentication enable default none

Use cases: Checking multiple related configuration lines (AAA, logging, NTP), verifying comprehensive security policies with multiple components, ensuring configuration bundles are complete.

must_not_match_any_from_array

Type: policyArray

Description: Configuration must contain NONE of the items from the comma-separated list. Policy passes only when all listed patterns are absent.

Example:

// Description: must_not_match_any_from_array No Insecure Protocols
#[must_not_match_any_from_array]
telnet, rsh, rexec, tftp

Use cases: Ensuring multiple deprecated protocols are disabled, verifying insecure services are completely absent, checking that test configurations are removed.

must_match_at_least_one_from_array

Type: policyArray

Description: Configuration must contain at least one item from the comma-separated list. Policy passes if any single element exists.

Example:

// Description: must_match_at_least_one_from_array Logging Configuration
#[must_match_at_least_one_from_array]
logging host 192.168.1.100, logging host 192.168.1.101, logging host 192.168.1.102

Use cases: Validating redundant configurations (multiple syslog servers, multiple NTP servers), ensuring at least one of several acceptable options is configured.

must_match_exactly_n_from_array

Type: policyArray

Description: Configuration must contain exactly N items from the comma-separated list, where N is specified in the policy assignment configuration.

Example:

// Description: must_match_exactly_n_from_array Exactly Two NTP Servers
#[must_match_exactly_n_from_array]
ntp server 192.168.1.1, ntp server 192.168.1.2, ntp server 192.168.1.3, ntp server 192.168.1.4

Use cases: Enforcing specific counts of redundant services (exactly 2 NTP servers), validating precise configuration requirements, ensuring neither too few nor too many of certain configurations exist.

Regex Matching Methods

must_match_regex

Type: policyRegex

Description: Configuration must match the regular expression pattern. Pattern must be enclosed in forward slashes with optional flags.

Example:

// Description: must_match_regex VTY Line Configuration
#[must_match_regex]
/.* vty 0 4.*/

Multi-line regex example:

// Description: must_match_regex RSTP Interface Edge Configuration
#[must_match_regex]
/^set protocols rstp interface (ge|xe|et)-\d+\/\d+\/\d+\.\d+ edge$/gm

Regex flags:

g: Global matching finds all occurrences
m: Multi-line mode allows ^ and $ to match line boundaries
i: Case-insensitive matching

Use cases: Matching configuration patterns with variable values (IP addresses, interface numbers), validating configuration structures across multiple vendors with syntax variations, complex multi-line configuration block validation.

must_not_match_regex

Type: policyRegex

Description: Configuration must NOT match the regular expression pattern. Policy passes when pattern is absent.

Example:

// Description: must_not_match_regex No Weak SSH Ciphers
#[must_not_match_regex]
/ssh.*cipher.*(des|rc4|md5)/i

Use cases: Ensuring insecure configurations are absent, verifying deprecated syntax is not present, checking that specific patterns do not exist anywhere in configuration.

must_match_all_regex_patterns

Type: policyRegexArray

Description: Configuration must match all patterns in a comma-separated list of regex patterns. All patterns must match for policy to pass.

Example:

// Description: must_match_all_regex_patterns Complete SNMP v3 Configuration
#[must_match_all_regex_patterns]
/snmp-server group .* v3 auth/, /snmp-server user .* .* v3 auth/, /snmp-server host .* version 3/

Use cases: Validating complete multi-component configurations, ensuring all elements of complex security policies exist, checking comprehensive protocol configurations.

must_match_at_least_one_regex

Type: policyRegexArray

Description: Configuration must match at least one pattern from a comma-separated list of regex patterns.

Example:

// Description: must_match_at_least_one_regex Any Valid Management Interface
#[must_match_at_least_one_regex]
/interface Vlan1\n ip address/, /interface Management\d+\n ip address/, /interface Loopback0\n ip address/

Use cases: Accepting multiple valid configuration approaches, validating that at least one of several alternatives exists, checking for flexible compliance requirements.

Code Block Matching Methods

match_code_block_from_array

Type: policyArray

Description: Matches sequential code blocks within configuration. Useful for matching ACLs, route-maps, interface configurations, etc. Passes compliance only when all lines in the policy array are matched sequentially in the evaluated configuration. Supports wildcards and regex patterns in the strings. Code block evaluation begins from the first match of the first line in the policy array.

Example:

// Description: Match code block from array
#[match_code_block_from_array]
* GigabitEthernet1, ip address *, negotiation auto

Use cases: Validating complete interface configurations, checking ACL entries in sequence, verifying route-map configurations, ensuring configuration blocks maintain specific structure and ordering.

match_code_block_flexible

Type: policyArray

Description: Flexible pattern matching that finds configuration elements anywhere within a logical block structure. Unlike sequential matching, this approach is order-agnostic and handles real-world configurations with comments, varying indentation, and different parameter ordering. Ideal for network protocols like LLDP, OSPF, BGP where configuration elements can appear in different orders. Automatically skips comment lines and empty lines. The method finds the configuration block using the first pattern, then searches for all other patterns within that block.

Example:

// Description: Flexible LLDP configuration matching
#[match_code_block_flexible]
protocols {, lldp {, management-address *;, interface all {, enable;, lldp-med {, location *;

Use cases: Validating protocol configurations with variable ordering, checking hierarchical configurations (Juniper-style), verifying configuration blocks where element order is not significant, handling configurations with comments and blank lines.

Advanced Methods

must_match_line_count

Type: policyLineCount

Description: Configuration line count must meet specified criteria including exact count, minimum, maximum, or range. Configured in the policy assignment rather than in the definition pattern.

Example:

// Description: must_match_line_count Configuration Minimum Size
#[must_match_line_count]

Use cases: Ensuring configurations meet minimum complexity requirements, detecting abnormally small configurations indicating incomplete provisioning, validating configuration file integrity.

custom_validation

Type: policyCustom

Description: Execute custom PHP validation logic for complex requirements not covered by standard methods. Requires PHP code implementation coordinated with rConfig support.

Example:

// Description: custom_validation Complex Security Policy
#[custom_validation]

Use cases: Highly specialized compliance requirements, mathematical calculations on configuration values, cross-referencing multiple configuration elements with complex logic.

Using the Policy Definition Editor

Accessing In-App Help

The policy definition editor provides comprehensive inline help documentation:

Navigate to Compliance → Policy Definitions
Click New Policy Definition or edit an existing policy
Click the Help icon (question mark or info icon) in the editor toolbar
The help panel displays all evaluation methods with descriptions and examples
Use the help panel as reference while creating policies

The help documentation displays the same method descriptions, examples, and use cases provided in this document, accessible directly within the editor without switching contexts.

Editor Features

Auto-completion: When typing #[, the editor displays all available method annotations with brief descriptions. Use arrow keys to navigate and Enter to select.

Syntax highlighting: Different colors distinguish comments, method annotations, and patterns, improving readability and error detection.

Keyboard shortcuts:

Ctrl+S (Windows/Linux) or Cmd+S (Mac): Save policy definition
Ctrl+Z: Undo changes
Ctrl+Y: Redo changes
Ctrl+F: Find text within policy definition

Validation feedback: The editor validates syntax as you type, highlighting errors before saving. Red underlines indicate syntax issues requiring correction.

Default template: When creating a new policy definition, rConfig inserts a template containing examples of all evaluation methods. You can add, remove, and edit these examples as needed for your specific requirements.

Editor Best Practices

Save frequently: Use Ctrl+S regularly to save work in progress, preventing loss from browser crashes or network issues.

Test incrementally: After adding several policies, save and test against sample configurations to verify behavior before adding more policies.

Use clear descriptions: Write descriptive comments explaining policy purpose and business rationale, not just technical implementation.

Organize logically: Group related policies together (e.g., all AAA policies, all logging policies) for easier maintenance.

Leverage the template: The default template provides working examples of each method. Modify these examples rather than writing from scratch to avoid syntax errors.

Common Policy Patterns

Security Hardening Policies

Typical security hardening policies for Cisco IOS devices:

// Description: must_match_single_string Disable CDP
#[must_match_single_string]
no cdp run

// Description: must_match_single_string Disable HTTP Server
#[must_match_single_string]
no ip http server

// Description: must_match_single_string Enable Password Encryption
#[must_match_single_string]
service password-encryption

// Description: must_match_all_from_array AAA Authentication
#[must_match_all_from_array]
aaa new-model, aaa authentication login default group tacacs+ local

// Description: wildcard_must_not_match_single_string No Test Interfaces
#[wildcard_must_not_match_single_string]
interface *test*

Logging and Monitoring Policies

Standard logging configuration policies:

// Description: must_match_at_least_one_from_array Syslog Server
#[must_match_at_least_one_from_array]
logging host 192.168.1.100, logging host 192.168.1.101

// Description: wildcard_match_single_string Logging Buffer Size
#[wildcard_match_single_string]
logging buffered *

// Description: must_match_regex Logging Facility
#[must_match_regex]
/logging facility (local[0-7]|auth|daemon|kern|mail|syslog|user)/

Interface Configuration Policies

Interface security and configuration standards:

// Description: match_code_block_from_array Standard Interface Configuration
#[match_code_block_from_array]
interface GigabitEthernet*, description *, switchport mode access, switchport port-security

// Description: must_match_regex Interface Description Required
#[must_match_regex]
/interface .+\n description .+/

// Description: must_not_match_regex No Shutdown on Unused Interfaces
#[must_not_match_regex]
/interface .+\n(?!.*shutdown)/

Protocol Configuration Policies

Network protocol compliance policies:

// Description: match_code_block_flexible LLDP Configuration
#[match_code_block_flexible]
protocols {, lldp {, management-address *;, interface all {, enable;

// Description: must_match_all_from_array NTP Servers
#[must_match_all_from_array]
ntp server 192.168.1.1, ntp server 192.168.1.2

// Description: wildcard_match_any_from_array SNMP Community Strings
#[wildcard_match_any_from_array]
snmp-server host *.*.*.* PROD-*, snmp-server host *.*.*.* MGMT-*

Troubleshooting

Symptom: Policy Fails to Save with Syntax Error

Diagnosis: Review error message for specific syntax issue.

Possible Causes:

Missing blank line between policy blocks
Method annotation not properly formatted with #[]
Regex pattern not enclosed in forward slashes
Array items not properly comma-separated

Resolution Steps:

Check that each policy block starts with a comment
Verify method annotation uses #[method_name] syntax exactly
Ensure regex patterns are wrapped in /pattern/ with appropriate flags
Confirm array items separated by commas without extra spaces around commas
Validate blank lines separate all policy blocks

Symptom: Wildcard Pattern Not Matching Expected Configurations

Diagnosis: Review wildcard syntax and test against sample configurations.

Possible Causes:

Wildcard characters (*, ?) not used correctly
Case sensitivity mismatch
Extra spaces or characters in pattern
Configuration line format differs from pattern

Resolution Steps:

Verify asterisk (*) for zero or more characters, question mark (?) for exactly one
Check that pattern case matches configuration exactly (case-sensitive)
Remove extra spaces from pattern
Compare pattern against actual device configuration line
Test with simpler pattern first, then add complexity incrementally

Symptom: Regex Policy Not Matching Expected Lines

Diagnosis: Test regex pattern independently.

Possible Causes:

Regex pattern syntax error
Missing or incorrect flags (g, m, i)
Special characters not properly escaped
Pattern too strict or too loose

Resolution Steps:

Extract sample configuration lines for testing
Use online regex tester (regex101.com) to test pattern
Verify pattern matches intended lines and excludes others
Check that flags are appropriate for match requirements
Adjust pattern and retest until behavior is correct

Symptom: Code Block Policy Matches Incorrectly

Diagnosis: Verify code block structure and ordering.

Possible Causes:

Using sequential method when flexible matching needed
Using flexible method when order matters
Pattern doesn’t match block start correctly
Configuration has unexpected formatting (comments, blank lines)

Resolution Steps:

Use match_code_block_from_array when element order matters (ACLs)
Use match_code_block_flexible when order is irrelevant (protocols)
Verify first pattern element clearly identifies block start
Test against actual device configuration with all formatting
Review compliance results for specific mismatch details

Symptom: Policy Evaluation Returns Unexpected Results

Diagnosis: Verify policy method matches intended evaluation logic.

Possible Causes:

Wrong evaluation method selected
Pattern not matching configuration exactly (case, spacing)
Configuration format differs from expected structure
Multi-line patterns not using appropriate flags

Resolution Steps:

Review evaluation method documentation in help panel
Confirm method selection matches desired behavior
Compare policy pattern against actual device configuration
Check for case sensitivity or spacing differences
Test policy against multiple device configurations to identify pattern

Best Practices

Policy Design

Start simple: Begin with straightforward string-matching policies before attempting complex regex patterns or code block matching. Build confidence with basic policies before tackling advanced requirements.

Test thoroughly: Test each policy against multiple device configurations representing different vendors, software versions, and configuration styles to ensure broad applicability.

Document intent: Write clear, descriptive comments explaining policy purpose, business rationale, and any special considerations. Future maintainers will appreciate context.

Use appropriate methods: Select the simplest evaluation method that meets requirements. Avoid regex complexity when string matching or wildcards suffice.

Leverage wildcards: Use wildcard matching (*, ?) for patterns with variable values before resorting to regex. Wildcards are more readable and easier to maintain.

Pattern Development

Reference the help panel: Keep the in-app help documentation open while developing policies. The examples provided cover most common use cases and can be adapted to your requirements.

Use the default template: The template inserted when creating new policy definitions contains working examples of every method. Modify these examples rather than writing from scratch.

Validate regex online: Use regex testing tools (regex101.com, regexr.com) to develop and validate patterns before deploying to policies. These tools provide detailed pattern analysis.

Test code blocks carefully: Code block matching methods are powerful but require careful testing. Verify they match intended blocks and don’t match unintended blocks with similar structure.

Comment complex patterns: For regex patterns or complex code blocks exceeding single-line readability, add comments explaining match logic and intent.

Maintenance

Review policies quarterly: Conduct regular policy reviews to identify obsolete policies, update patterns for new software versions, and refine based on operational experience.

Track policy effectiveness: Monitor compliance results to identify policies with high false-positive rates requiring refinement or those never triggering violations that may be obsolete.

Standardize policy libraries: Develop organizational standard policy libraries for common device types and security frameworks, promoting consistency across teams.

Document exceptions: When devices legitimately fail policies, document approved exceptions with business justification and review dates.

Keep documentation current: When modifying policies, update comments to reflect current intent and business rationale.

Policy Definitions - Complete compliance policy documentation
Policy Assignments - Assigning policies to devices
Policy Compliance Results - Reviewing compliance outcomes
Compliance Suite Overview - Complete compliance framework

Summary

The simplified policy definition format in rConfig V8 dramatically improves policy creation efficiency, readability, and maintainability. Organizations can leverage comment-and-annotation syntax with powerful evaluation methods including wildcard matching, flexible code block matching, and comprehensive regex support to develop compliance policies rapidly and accurately.

Key takeaways for effective policy definition:

Reference in-app help documentation directly within the editor for method examples and guidance
Start with the default template containing working examples of all evaluation methods
Use wildcards (*, ?) for variable values before resorting to regex patterns
Select appropriate code block methods based on whether element ordering matters
Test policies thoroughly against diverse device configurations before production deployment
Document policy intent clearly in comments to facilitate future maintenance and review

The policy definition format provides a solid foundation for building comprehensive compliance programs that scale from small deployments to enterprise environments managing thousands of devices across multiple vendors and regulatory frameworks. The combination of simple syntax, powerful evaluation methods, and integrated help documentation enables teams to create sophisticated compliance policies efficiently and maintainably.

Policy Definition File Format

Policy Definition File Format: Syntax and Validation Methods for Network Configuration Compliance

Understanding the Policy Definition Format

Format Structure

Format Benefits

Format Rules and Syntax

Basic Format Rules

Wildcard Syntax

Policy Evaluation Methods

String Matching Methods

Wildcard Matching Methods

Array Matching Methods

Regex Matching Methods

Code Block Matching Methods

Advanced Methods

Using the Policy Definition Editor

Accessing In-App Help

Editor Features

Editor Best Practices

Common Policy Patterns

Security Hardening Policies

Logging and Monitoring Policies

Interface Configuration Policies

Protocol Configuration Policies

Troubleshooting

Symptom: Policy Fails to Save with Syntax Error

Symptom: Wildcard Pattern Not Matching Expected Configurations

Symptom: Regex Policy Not Matching Expected Lines

Symptom: Code Block Policy Matches Incorrectly

Symptom: Policy Evaluation Returns Unexpected Results

Best Practices

Policy Design

Pattern Development

Maintenance

Related Documentation

Summary