To illustrate the Must Contain Rules, you can build an Attributed Compliance Test that tests AccessList 197. Its primary Query will retrieve the rules (AclExtendedRule) from the AccessList named “197” from the Device being tested. The Join list for this Query is illustrated in Must Contain Rules query.
The Column selections for this Query are illustrated inMust Contain Rules query Column selections.
(Recall the basic is a projection with all the basic columns of our AclExtendedRule).
The Selection list for this Query is illustrated in Must Contain Rules query Selection list.
This selection clause selects the Access List named 197 (Cisco access lists are often named by a number).
We know that AccessList rules are ordered, and must appear in order. For that reason we check “Must Contain Ordered Match” on the test’s Properties tab. Since we want to specify the entire access list in our rules (and not allow the Device to have any additional rules other than those we specify), we also check “Must Contain Exact Match” on the Properties tab.
The Must Contain rules are illustrated in Must Contain Rules.
This has two explicitly specified permit rules listed first, with SrcIpAddress entries of 192.168.0.25 and 192.168.0.30. Next appears a line with three asterisks in the first column “***”; this signifies a wild-card match in an ordered test that will match any number of arbitrary rows in the result set. Next appears another explicitly specified permit, and a deny.
Any blank cells in the Match Each Row rules are interpreted as “Don’t Cares”, meaning that attribute can appear as anything (or null) in the result set and the rule still matches.
The rules specify an Address and NetMask (this is a function of the model). The Netmask is not a Wildcard or inverse-mask; rather the model normalizes access rules to network masks, inverting the mask if necessary on a particular Device. Note also that the deny rule uses address and mask both set to 0.0.0.0; this is equivalent to “any”.