Per-device values and exceptions

The policy definition format has no variables. There are no placeholders, no per-device substitution, no includes and no device conditions. rConfig evaluates the same definition text against every device in an assignment’s scope, and every value in it is literal.

So when a value differs between devices, such as a loopback address, a site’s NTP server or a port’s VLAN, you have three options: match the varying part loosely, split devices into groups with their own definitions, or build the exception into the rule. This page shows each with results asserted by the rConfig Pro test suite.

---

Match the varying part loosely

Wildcards in a line

* matches any run of characters and ? matches exactly one. Both stay within a single line. Wildcard methods are case-sensitive.

// A trap host in 192.0.x.x uses community EXAMPLECOMM10
#[wildcard_match_single_string]
snmp-server host *.0.?.? EXAMPLECOMM10

// A trap host matching *.2.1.? uses community EXAMPLECOMM10
#[wildcard_match_single_string]
snmp-server host *.2.1.? EXAMPLECOMM10

// All three wildcard lines are present
#[wildcard_match_all_from_array]
snmp-server host 192.0.2.1 EXAMPLECOMM*
snmp-server host 192.0.?.? EXAMPLECOMM30
aaa session*

// All three wildcard lines are present (one is not)
#[wildcard_match_all_from_array]
snmp-server host 192.0.2.1 EXAMPLECOMM*
snmp-server host *.2.1.? EXAMPLECOMM10
aaa session*

Against the IOS-XE excerpt on must contain and must not contain:

Rule	Result	Why
*.0.?.?	pass	Matches snmp-server host 192.0.2.2 EXAMPLECOMM10.
*.2.1.?	fail	No trap host address contains .2.1..
All three, all present	pass	Each line matches somewhere.
All three, one missing	fail	The *.2.1.? line matches nothing.

Source: PolicyMethodsTest::test_wildcard_match_single_string_tests and test_wildcard_match_all_from_array_tests. Minimum version 8.0.0.

Caution

Wildcard patterns are not anchored to the start or end of a line, so snmp-server host 192.0.2.1 EXAMPLECOMM* would also match inside a longer line, such as one starting with no . ? matches any single character, including a dot or a space. Wildcards make a rule easier to pass, so check that the looser rule still fails on the configs it should.

Wildcards inside a section

The same wildcards work in code block methods, which is the usual way to say “this port must have an access VLAN” without naming it:

// Port 6/0/48 has an access VLAN, a voice VLAN and the port-security limit
#[match_code_block_strict]
interface GigabitEthernet6/0/48
switchport access vlan *
switchport voice vlan *
switchport port-security maximum 100

Against the two-port config on section-scoped checks, the result is pass. Source: CustomerUseCases/MatchCodeBlockStrictTest::test_literal_anchor_with_wildcard_values_in_body. Minimum version 8.2.2.

Regular expressions

When “anything” is too loose, a regex can restrict the value to a range or a list of alternatives. See regex patterns.

---

Split devices into groups

When groups of devices need different literal values, give each group its own definition and its own assignment. An assignment’s scope can be a single device, a command group, a tag or a smart group, so a site tag or a role tag usually maps cleanly onto a definition. See Policy Assignments.

The same approach handles a device that is a permanent exception: keep it out of the scope of the standard assignment, and give it an assignment of its own if it still needs checking.

---

Build the exception into the rule

evaluate_block (8.3.0 and later) can express “this rule applies unless…”. Put the exception and the requirement under any:, so a section passes if it is exempt or compliant.

This F5 BIG-IP rule (sanitised from the F5 WAF tests) requires a WAF policy on every virtual server, except servers that are disabled or are not reachable from any source:

// F5 WAF for external servers: every externally reachable virtual server has a WAF policy (disabled servers are skipped)
#[evaluate_block]
scope: ^ltm virtual
any:
  - equals: disabled
  - not: source 0.0.0.0/0
  - ASM_WAF_

Passing config: an external server with a WAF policy.

ltm virtual /Common/vs_ext_ok {
    destination /Common/192.0.2.10:443
    profiles {
        /Common/ASM_WAF_policy_prod { }
    }
    source 0.0.0.0/0
}

Failing config: an external server without one.

ltm virtual /Common/vs_ext_bad {
    destination /Common/192.0.2.10:443
    profiles {
    }
    source 0.0.0.0/0
}

Exempt, so passing: the same server, disabled.

ltm virtual /Common/vs_ext_disabled {
    destination /Common/192.0.2.10:443
    disabled
    profiles {
    }
    source 0.0.0.0/0
}

Not applicable, so passing: an internal-only server without a WAF policy.

ltm virtual /Common/vs_internal {
    destination /Common/192.0.2.10:443
    profiles {
    }
    source 198.51.100.0/24
}

Config	Rule result	Failing section recorded
External, WAF policy	pass	None
External, no WAF policy	fail	ltm virtual /Common/vs_ext_bad {
Disabled	pass	None
Internal only	pass	None

Source: CustomerUseCases/F5WafBlockComplianceCustomerTest (external servers tests). Minimum version 8.3.0.

The exemption uses equals: disabled rather than a plain disabled item on purpose. A plain item matches part of any line, so it would also match a profile with disabled in its name. Avoiding false positives shows the test for this.