Understanding Junos Snapshot Administrator Test Operators
Junos Snapshot Administrator enables you to capture and audit
runtime environment snapshots of your networked devices running Junos
OS. The Junos Snapshot Administrator configuration file defines the
scope of a snapshot and the evaluation criteria for either a single
snapshot or a comparison of two snapshots. The Junos Snapshot Administrator --snapcheck option takes a single snapshot and evaluates
the results, and the --check option compares
the results of two separate snapshots. Within the configuration file,
you can create test cases that evaluate or compare content from specific
Junos OS operational mode commands. The test cases use test operators
to either evaluate data elements in a single snapshot or compare data
elements in two separate snapshots.
Junos Snapshot Administrator provides numerous relational operators that test for existence, equality, inequality, size, and inclusion in or exclusion from a specific range or list. Specific operators work with different operand types including strings, numbers, and XML elements. You should construct test cases using test operators that pertain to the type of check being performed. For a list of available operators, see Junos Snapshot Administrator Test Operators Summary.
Junos Snapshot Administrator uses a few test operators, delta, list-no-less, list-no-more, and no-diff, to compare elements or element values in two separate snapshots.
Test cases using these test operators are executed when you use the --check option. When you use the --snapcheck option, which is specific to a single collection, test cases using
these test operators are effectively ignored. Junos Snapshot Administrator
outputs a message when a test case is ignored, as shown in the following
sample output:
--------------------------------------------------------------------------- CHECKING SECTION: ospf-checks --------------------------------------------------------------------------- INFO: snapcheck mode: skipping test: list-not-less INFO: snapcheck mode: skipping test: no-diff + TEST PASSED: All OSPF neighbors are up + TEST PASSED: OSPF neighbors must have the same priority value INFO: snapcheck mode: skipping test: no-diff
When comparing element values across two snapshots, in order
to map the first snapshot data item to the second snapshot data item,
you must select elements of the data that create a unique ID. To create
a unique ID for a test case, you include the id statement followed by an XPath expression that references the unique
element. To create a unique ID based on multiple element values, you
define multiple id statements. You can
also construct ID values relative to the content value.
Consider the following XML data for the show ospf
neighbor operational mode command.
<ospf-neighbor-information>
<ospf-neighbor>
<neighbor-address>10.10.115.169</neighbor-address>
<interface-name>ae18.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>10.10.20.170</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>3</activity-timer>
</ospf-neighbor>
<ospf-neighbor>
<neighbor-address>10.10.115.174</neighbor-address>
<interface-name>ae19.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>10.10.20.168</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>3</activity-timer>
</ospf-neighbor>
</ospf-neighbor-information>
For this case, you can create a unique ID using the value of
the interface-name element, which is a
child element of ospf-neighbor. You specify
the ID using the id statement followed
by the interface-name XPath expression.
ospf-neighbor-check {
command show ospf neighbor;
iterate ospf-neighbor {
id interface-name;
#
# test-cases
#
}
}
To create a unique ID based on multiple element values, you
define multiple id statements. The following
example uniquely identifies an OSPF neighbor by the values of both
the interface-name and the neighbor-id elements:
ospf-neighbor-check {
command show ospf neighbor;
iterate ospf-neighbor {
id interface-name;
id neighbor-id;
#
# test-cases
#
}
}
You can also construct ID values relative to the content value.
The following example creates a unique ID for a VPLS connection using
three values: the VPLS instance-name, the local-site-id within the VPLS service, and the connection-id of the connection.
vpls-list {
command show vpls connections up;
iterate instance//connection {
id connection-id;
id ../local-site-id;
id ancestor::instance/instance-name;
list-not-less {
info Check VPLS connections - all back up;
err " VPLS connection missing on service %s", $ID.3;
err " Site: %s, connection-id: %s", $ID.2, $ID.1;
err " Remote-PE: %s", remote-pe;
err " local-interface: %s", local-interface/interface-name;
}
}
}
The previous code defines the content data as the set of connection
items, which are selected by the XPath expression instance//connection. Each connection has a connection-id,
which defines the first id value. Each
connection has a parent element local-site, which has a local-site-id child element.
Therefore, the second id value is ../local-site-id. The third id value, ancestor::instance/instance-name, is an XPath expression that means: starting from the connection,
go up through the XML parent hierarchy (ancestor) until you find the instance element, and then select the instance-name value. The result is the VPLS service
name.
Junos Snapshot Administrator uses special $ID.num variables that map to the id statements in a test section. When you define one
or more id statements in a test section,
you can use these variables to refer to the XPath expression throughout
that test case. This is useful when the XPath expression gets too
long. Note the use of the $ID variables
in the err statements in the previous example.
For more information about Junos Snapshot Administrator variables,
see Understanding Junos Snapshot Administrator Reference Variables.