...
Loose
Sequential
Strict
Loose mode - verifies that all input lines must be are present in the source. Their order does not matter, and additional lines may appear between them.
Sequential mode - verifies that all input lines must appear are present in the source in the same order as entered. Additional lines may appear between them.
Strict mode - verifies that all input lines must appear are present in the source in the same order as entered and consecutively in the source. No additional lines may appear between themthe matching lines.
Match mode | Line order matters | Lines must be consecutive |
|---|---|---|
Loose | No | No |
Sequential | Yes | No |
Strict | Yes | Yes |
...
The compliance condition examples throughout this article are evaluated against the following theoretical configuration snippet. The example snippet represents only a portion of the device configuration; other configuration sections backup. This is a theoretical example containing only the relevant configuration lines; many config lines that would normally appear in a real backup are omitted for brevity.
| Code Block | ||
|---|---|---|
| ||
hostname R1 ! interface Ethernet1 description Uplink ip address 10.0.0.1 255.255.255.0 no shutdown ! interface Ethernet2 description LAN ip address 192.168.1.1 255.255.255.0 no shutdown ! interface Loopback0 description Management Loopback ip address 10.255.255.1 255.255.255.255 ! router ospf router-id 1.1.1.1 network 10.0.0.0 0.0.0.255 area 0 ! |
...
Note: The Compliance module can validate MCP automation outputs in addition to device configurations. To validate an automation output, select Source → Mass Config Push Result on the Compliance preset screen. The same condition types and matching principles described in this article apply when evaluating automation output.
Loose mode:
Loose mode verifies that all input lines are present in the source. Their order does not matter, and additional lines may appear between them.
Source contains
The following examples demonstrate how Loose mode evaluates input lines when using the Source contains condition type.
...
| Code Block | ||
|---|---|---|
| ||
description LAN hostname R1 |
ResultStatus: Condition successful
Although the order of the input lines differs from the source, both lines are present.
...
| Code Block | ||
|---|---|---|
| ||
hostname R1 description WAN |
ResultStatus: Condition failed
The line description WAN does not exist in the source.
...
| Code Block | ||
|---|---|---|
| ||
router ospf hostname R[0-9]+ |
ResultStatus: Condition successful
This verifies that the device follows the R<number> hostname convention and has OSPF enabled. The order of the matches does not matter.
...
| Code Block | ||
|---|---|---|
| ||
router ospf hostname R[A-Z]+ |
ResultStatus: Condition failed
The router ospf line matches the source, but hostname R[A-Z]+ regex does not match hostname R1. Because all input lines must match the source, the condition fails.
Sequential mode:
Sequential mode requires all input lines to be present in the source in the same order as entered. Additional lines may appear between them.
Source contains
The following examples demonstrate how Sequential mode evaluates input lines when using the Source contains condition type.
...
| Code Block | ||
|---|---|---|
| ||
interface Ethernet1 ip address 10.0.0.1 255.255.255.0 |
ResultStatus: Condition successful
Both input lines appear in the source in the correct order. The "description Uplink" line between them is ignored.
...
| Code Block | ||
|---|---|---|
| ||
ip address 10.0.0.1 255.255.255.0 interface Ethernet1 |
ResultStatus: Condition failed
The input lines appear in the source in reverse order.
...
| Code Block | ||
|---|---|---|
| ||
router ospf network [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ 0\.0\.0\.[0-9]+ area [0-9]+ |
ResultStatus: Condition successful
This verifies that an OSPF network statement appears after the "router ospf" command. Other matching lines may appear between the two lines.
...
| Code Block | ||
|---|---|---|
| ||
network [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ 0\.0\.0\.[0-9]+ area [0-9]+ router ospf |
ResultStatus: Condition failed
Both lines are present in the source, but they appear in the opposite order. Sequential mode therefore fails.
Strict mode:
Strict mode requires input lines to be present in the same order as entered and consecutively in the source. No additional lines may appear between the matching lines.
Source contains
The following examples demonstrate how Strict mode evaluates input lines when using the Source contains condition type.
...
| Code Block | ||
|---|---|---|
| ||
interface Ethernet1 description Uplink ip address 10.0.0.1 255.255.255.0 |
ResultStatus: Condition successful
All three lines appear consecutively in the source.
...
| Code Block | ||
|---|---|---|
| ||
interface Ethernet1 ip address 10.0.0.1 255.255.255.0 |
ResultStatus: Condition failed
The source contains the line "description Uplink" between the two input lines. Strict mode therefore fails.
...
| Code Block | ||
|---|---|---|
| ||
interface Loopback[0-9]+ description Management Loopback ip address 10\.255\.255\.[0-9]+ 255\.255\.255\.255 |
ResultStatus: Condition successful
This verifies that a Loopback interface with a variable interface number has the required "Management Loopback" description and uses a /32 address matching the 10.255.255.x pattern.
...
| Code Block | ||
|---|---|---|
| ||
interface Loopback[0-9]+ ip address 10\.255\.255\.[0-9]+ 255\.255\.255\.255 |
ResultStatus: Condition failed
Both lines match in the source, but the description Management Loopback line appears between them. Strict mode requires the matching lines to be consecutive, so the condition fails.
Choosing the right Match mode
...
Requirement
...
Recommended match mode
...
Required lines can appear anywhere and in any order
...
Loose
...
Required lines must appear in a specific order, but may have other lines between them
...
Sequential
...
Required lines must appear in a specific order with no lines between them
...
Strict
Common use cases:
The following are some example scenarios where each match mode is particularly useful:
...
examples illustrate common configuration validation scenarios and the match mode best suited to each.
| Config to validate | Match mode | Rationale | |||
|---|---|---|---|---|---|
| Baseline configuration and security hardening - NTP servers, AAA, logging...DNS servers, syslog host, password encryption, telnet disabled, HTTP disabled | Loose | Requirements are independent lines scattered across the config, only presence matters | |||
| Security hardening - telnet disabled, no SNMPv2, management ACLs... | Loose | Independent requirements with no meaningful ordering relative to each other | |||
| Firewall and ACL rules | Sequential | Rule ordering matters, such as when specific rules must precede broader rules. | |||
| RouteThe required lines are independent of each other and may appear in different parts of the configuration. Only their presence matters. | |||||
| Firewall and ACL rules, route-maps | Sequential | Match and set clauses The required lines must appear in a required sequencespecific order, while other configuration lines may appear between them. | |||
| Multiline MOTD banner, interface configurations | Strict | The required lines form a complete banner configuration block must be present and uninterrupted | Interface config blocks | Strict | Validate that a required set of interface configuration commands appears together as a consecutive blockand must appear consecutively without any other lines between them. |