Skip to content

Validation Rule Types Reference

This guide covers the rule types available when creating a Validation Rule. The rule type determines how the app compares data during the Compare Snapshots job.

You configure the rule type and its options on the Validation Rule form:

  • Rule Type -- Which comparison strategy to use
  • Rule Options -- A JSON object with type-specific parameters (some types require options, others don't)

Quick Reference

Rule Type Rule Options Compares
EXACT_MATCH null Pre vs. Post -- fails if anything changed
TOLERANCE {"tolerance": 10} Pre vs. Post -- fails if numeric difference exceeds tolerance threshold
PARAMETER_MATCH {"params": {"key": "value"}, "mode": "match"} Post vs. Expected -- fails if post data doesn't match expected values
OPERATOR {"params": {"operator": "is-gt", "operator_data": 0}} Post vs. Threshold -- fails if post data doesn't meet the condition
REGEX {"pattern": "^regex$"} Post vs. Pattern -- fails if post data doesn't match the regex

Pre vs. Post or Post vs. Expected?

EXACT_MATCH and TOLERANCE compare your "pre" snapshot data against your "post" snapshot data to detect what changed. PARAMETER_MATCH, OPERATOR, and REGEX work differently -- they evaluate the "post" snapshot's data against values you define in the rule options, and the "pre" snapshot's data is not used. The Compare Snapshots job still requires both snapshots to run, but for these three rule types only the "post" snapshot is evaluated.

EXACT_MATCH

The simplest and most common rule type. Fails if there is any difference between the "pre" and "post" data.

Rule Options: null

When to use: When you want to verify that nothing changed at all -- interface status, BGP neighbors, device facts, configuration elements, etc.

Example: Device Facts

Verify that device facts (hostname, model, OS version) remain unchanged after a maintenance window.

Command Parser setup:

  • Parser: NAPALM
  • NAPALM Getter: get_facts
  • Path: *

Validation Rule setup:

  • Rule Type: EXACT_MATCH
  • Rule Options: null

Sample "pre" snapshot data:

{
  "fqdn": "router1.example.com",
  "model": "C8000V",
  "os_version": "17.12.2",
  "serial_number": "ABC123"
}

If any field changes between the "pre" and "post" snapshots, the result will be Fail with a diff showing exactly what changed. For example, if os_version changed:

{
  "os_version": {
    "old_value": "17.12.2",
    "new_value": "17.13.1"
  }
}

Example: Interface Status

Verify that all Loopback interfaces remain up.

Command Parser setup:

  • Parser: TEXTFSM
  • Command: show interfaces
  • Path: [?starts_with(interface, 'Loopback')].[interface, link_status, protocol_status]

Validation Rule setup:

  • Rule Type: EXACT_MATCH
  • Rule Options: null

Using Exclude with EXACT_MATCH

When using EXACT_MATCH with Path: * (raw mode), you can use the Exclude field on the Command Parser to ignore noisy fields like counters or statistics. See the Command Parser Reference for details.

TOLERANCE

Compares "pre" and "post" data, but allows numeric values to vary within a specified threshold. Useful when values are expected to fluctuate slightly between snapshots.

Rule Options (required):

{"tolerance": 10}

The tolerance value defines the maximum allowed absolute difference (plus or minus) between the "pre" and "post" values. For example, {"tolerance": 5} means a value of 100 in "pre" and 104 in "post" would pass (difference of 4), but 106 would fail (difference of 6).

Warning

Tolerance is an absolute value, not a percentage. {"tolerance": 5} means the value can differ by up to ±5 units, regardless of the original value.

When to use: BGP prefix counts, interface counters, performance metrics -- anywhere that small numeric fluctuations are normal and shouldn't be flagged.

Example: BGP Prefix Count Monitoring

Allow up to 5 prefix difference per BGP neighbor to account for normal route fluctuations.

Command Parser setup:

  • Parser: TEXTFSM
  • Command: show ip bgp summary
  • Path: [*].[$neighbor$, state_pfxrcd]

Validation Rule setup:

  • Rule Type: TOLERANCE
  • Rule Options: {"tolerance": 5}

Sample "pre" snapshot data:

[
  ["10.1.1.1", 150],
  ["10.1.1.2", 75],
  ["10.1.1.3", 200]
]

If the "post" snapshot prefix count for 10.1.1.1 is 148, that's within the tolerance of 5, so it passes. If it drops to 140, that's a difference of 10, which exceeds the tolerance and fails.

PARAMETER_MATCH

Checks that the "post" snapshot data matches expected values you define in the rule options. Unlike EXACT_MATCH and TOLERANCE, this rule type does not compare "pre" vs. "post" -- it validates the "post" data against a target you specify.

Rule Options (required):

{"params": {"field_name": "expected_value"}, "mode": "match"}

When to use: OS version compliance after upgrades, hardware model verification, feature checks -- anywhere you need to confirm that a specific field has a specific value after a change.

Example: OS Version Compliance

After an OS upgrade, verify that the device is running the target version.

Command Parser setup:

  • Parser: NAPALM
  • NAPALM Getter: get_facts
  • Path: os_version

Validation Rule setup:

  • Rule Type: PARAMETER_MATCH
  • Rule Options: {"params": {"os_version": "17.12.2"}, "mode": "match"}

Sample "post" snapshot data:

"Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.12.2, RELEASE SOFTWARE (fc2)"

The rule checks if the extracted os_version value contains "17.12.2". If it does, the result is Pass.

OPERATOR

Validates the "post" snapshot data against a threshold using comparison operators. Like PARAMETER_MATCH, this does not compare "pre" vs. "post" -- it checks whether the "post" data meets a condition you define.

Rule Options (required):

{"params": {"operator": "is-gt", "operator_data": 100}}

Supported Operators:

Operator Meaning Example operator_data
is-gt Greater than 0
is-lt Less than 90
is-ge Greater than or equal 1
is-le Less than or equal 100
in-range Value is within range [10, 90]
not-in-range Value is outside range [10, 90]
is-in Value is in the list ["up", "dormant"]
not-in Value is not in the list ["down", "disabled"]
contains Value contains substring "Established"
not-contains Value does not contain substring "error"
all-same All values are identical (none needed)
is-subset Value is a subset of operator_data ["a", "b", "c"]
is-subset-ci Case-insensitive subset check ["a", "b", "c"]

When to use: Threshold monitoring, range checks, status validation, performance baselines.

Example: Uptime Check

Verify that device uptime is greater than 0 (confirming the device didn't reboot unexpectedly).

Command Parser setup:

  • Parser: NAPALM
  • NAPALM Getter: get_facts
  • Path: uptime

Validation Rule setup:

  • Rule Type: OPERATOR
  • Rule Options: {"params": {"operator": "is-gt", "operator_data": 0}}

Example: Interface Status in Allowed States

Verify that an interface's status is one of the acceptable values.

Command Parser setup:

  • Parser: TEXTFSM
  • Command: show interfaces
  • Path: [?interface == 'GigabitEthernet1'].link_status | [0]

Validation Rule setup:

  • Rule Type: OPERATOR
  • Rule Options: {"params": {"operator": "is-in", "operator_data": ["up", "dormant"]}}

REGEX

Validates that the "post" snapshot data matches a regular expression pattern. Like PARAMETER_MATCH and OPERATOR, this does not compare "pre" vs. "post" -- it validates the "post" data against a pattern you define.

Rule Options (required):

{"pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"}

Note

Backslashes in regex patterns must be double-escaped in JSON. For example, \d becomes \\d.

When to use: Version string format validation, IP address format checks, serial number patterns, interface naming conventions.

Example: Version String Format

Verify that the OS version follows a major.minor.patch format.

Command Parser setup:

  • Parser: NAPALM
  • NAPALM Getter: get_facts
  • Path: version

Validation Rule setup:

  • Rule Type: REGEX
  • Rule Options: {"pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"}

Sample "post" snapshot data:

"17.12.2"

The regex matches the major.minor.patch pattern, so the result is Pass. A value like "17.12.2a" would Fail.

Choosing the Right Rule Type

I want to... Use
Check that nothing changed between "pre" and "post" EXACT_MATCH
Allow small numeric differences between "pre" and "post" TOLERANCE
Verify a field has a specific expected value PARAMETER_MATCH
Check a value against a numeric threshold or allowed list OPERATOR
Validate a value matches a text pattern REGEX

Testing Your Rules

Before deploying validation rules in production:

  1. Test JMESPath expressions using the JMESPath online tester with sample device output
  2. Run a test snapshot on a small set of devices to verify the collected data looks correct
  3. Make a known change and run a second snapshot to create a comparison with predictable differences
  4. Review the diff output to confirm the rule catches what you expect and doesn't flag false positives