Policy Library

The Policy Library is a set of worked policy definition examples. Each example gives you the definition to copy, a config that passes, a config that fails, and the result rConfig reports for each. The Policy Definitions reference explains the file format and every method. This library shows the methods applied to real configuration problems.

Note

Policy compliance is a Pro feature, available in the Pro, Vector and Enterprise editions. Each example states the minimum rConfig version for the methods it uses.

---

Where the examples come from

Every example in this library is taken from the automated test suite that ships with rConfig Pro. A test in that suite runs the definition against the config and asserts the result shown here. If no test asserts a result, the example is not in the library. That is why the library is small for now: we would rather publish fewer examples than ones we have not proven.

The configs have been sanitised before publication: documentation IP ranges (RFC 5737 and RFC 3849), example.com hostnames, and fake hashes, keys and SNMP communities. Sanitising never changes whether an example passes or fails.

How the library is organised

Section	What it holds
Your first policy	A tutorial: write one IOS-XE rule, test it, assign it, and read the result.
Patterns	Vendor-neutral techniques: must contain and must not contain, section-scoped checks, regex patterns, per-device values and exceptions and avoiding false positives.
Platforms	Rules grouped by operating system and topic: Cisco IOS-XE. More platforms are added as tested rules become available.
Frameworks	Framework mappings. Coming in a later release.

Start with the platform pages if you know what you want to check. Read the patterns first if you are writing your own rules, especially avoiding false positives.

Using an example

1. Copy the definition into a new or existing policy definition under Compliance → Definitions.
2. Change the values (servers, account names, VLANs) to match your standard. The format has no variables, so every value is written literally. See per-device values and exceptions.
3. Test it against a stored config with Test Policy Definition before you assign it. The policy development workflow covers this in detail.
4. Assign it to the devices it applies to under Compliance → Assignments.

If you change a definition beyond the values, the published result no longer applies. Test it against your own passing and failing configs.

Status

Each rule page has one of two statuses, listed in the Status column of its platform index:

Status	Meaning
Verified	The example configs are derived from sanitised real device output.
Lab tested	The example configs were written for the test, from vendor documentation or lab configs.

Both statuses mean an automated rConfig test asserts the result. Neither is a claim about a particular device or software release.

Minimum versions

Methods	Minimum rConfig version
Single-string, array and wildcard methods, must_match_regex, match_code_block_from_array, match_code_block_flexible	8.0.0
must_not_match_regex, wildcard_must_not_match_single_string	8.0.2
match_code_block_strict	8.2.2
evaluate_block	8.3.0

A definition needs the highest minimum version of any method it contains.