...
| Code Block | ||
|---|---|---|
| ||
hostname R1 ! interface Ethernet1 description Uplink ip address 10.0.0.1/24 no shutdown ! interface Ethernet2 description LAN ip address 192.168.1.1/24 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/24 area 0 ! |
Note: The Compliance engine can validate MCP automation outputs in addition to device configurations. To validate an automation output, select Source → Mass Config Push Result. The same condition types and matching principles described in this article apply when evaluating automation output.
...
| Code Block | ||
|---|---|---|
| ||
(?m)^hostname R[0-9]+$^router ospf$ (?m)^interface^hostname EthernetR[0-9]+$ |
This checks for a hostname matching R followed by one or more digits and an Ethernet interface with a numeric identifier. The two matches can occur anywhere in the configuration and in any orderverifies that the device follows the R<number> hostname convention and has OSPF enabled. The two matches are independent, so their order does not matter.
Sequential Mode
| Code Block | ||
|---|---|---|
| ||
(?m)^interface Ethernet[0-9]+$^router ospf$ (?m)^ ipnetwork address ([0-9]{1,3}+\.){3}[0-9]{1,3}/+\.[0-9]+\.[0-9]+/([0-9]+) area [0-9]+$ |
This verifies that an interface declaration OSPF configuration section is followed later by an IPv4 addressOSPF network statement. Other configuration lines OSPF configuration, such as a router-id, may appear between the two matches.
Strict Mode
| Code Block | ||
|---|---|---|
| ||
(?m)^interface EthernetLoopback[0-9]+$ (?m)^ description .+$Management Loopback$ (?m)^ ip address ([0-9]{1,3}\.){3}10\.255\.255\.[0-9]{1,3}/[0-9]+$+ 255\.255\.255\.255$ |
This verifies that an a Loopback interface , a description, and an IPv4 address appear as three consecutive lines, in that order.with a variable interface number has the required "Management Loopback" description and uses a /32 address from the 10.255.255.0/24 management subnet.
Choosing the Right Match Mode
Use case | Recommended mode |
|---|---|
Verify several independent configuration lines exist in the source | Loose |
Verify the presence and order of configuration commands in the source | Sequential |
Verify an exact the presence of a configuration block | Strict |
Common use cases:
Required security commands
Requirement:
Every device must have SSH version 2, password encryption, and a configured NTP server.
Recommended: Loose
The commands are independent requirements; their order is not important.
Interface configuration structure
Requirement:
An interface declaration must be followed somewhere later in the same configuration section by its IP address.
Recommended: Sequential
The order matters, but other interface configuration may appear between the two matches.
Approved configuration template
Requirement:
An interface must contain an exact three-line configuration block with no additional commands between the required lines.
Recommended: Strict
The exact structure is part of the requirement.
Multiple approved alternatives
Requirement:
Devices must use either TACACS+ or RADIUS authentication.
Recommended: Multiple conditions with OR
Each authentication method is represented by a separate condition, and the rule succeeds if either condition matches.
Complete security baseline
Requirement:
Devices must have SSH version 2, a configured TACACS+ server, and HTTP disabled.
Recommended: Multiple conditions with AND
Each individual requirement is evaluated separately, and the rule succeeds only when all requirements are satisfied.