circle-info
NSO 6.7 is here!
Explore the highlights to discover what's newarrow-up-right
search
Ctrlk
NSO DevCenterTry NSO

Compliance Reporting

Audit and verify your network for configuration compliance.

When the network configuration is broken, there is a need to gather information and verify the network. NSO has numerous functions to show different aspects of such a network configuration verification. However, to simplify this task, compliance reporting can assemble information using a selection of these NSO functions and present the resulting information in one report. This report aims to answer two fundamental questions:

  • Who has done what?

  • Is the network correctly configured?

What defines a correctly configured network? Where is the authoritative configuration kept? Naturally, NSO, with the configurations stored in CDB, is the authority. Checking the live devices against the NSO-stored device configuration is a fundamental part of compliance reporting. Compliance reporting can also be based on one or a number of stored templates which the live devices are compared against. The compliance reports can also be a combination of both approaches.

Compliance reporting can be configured to check the current situation, check historical events, or both. To assemble historical events, rollback files are used. Therefore this functionality must be enabled in NSO before report execution, otherwise, the history view cannot be presented.

The reports are stored in a SQLite database file and can be exported to plain text, HTML or DocBook XML format. The report results can be re-exported to a new format at any time. The DocBook XML format allows you to use the report in further post-processing, such as creating a PDF using Apache FOP and your own custom styling. Every consecutive run of the report is stored in the same SQLite database. This allows for comparing the report results over time and one such comparison is available in the Web UI. The previous behavior before NSO 6.5 of getting one SQLite file per report run is available by setting common-db under the report definition to false.

circle-info

Reports can be generated using either the CLI or Web UI. The suggested and favored way of generating compliance reports is via the Web UI, which provides a convenient way of creating, configuring, and consuming compliance reports. In the NSO Web UI, compliance reporting options are accessible from the Tools menu (see Web User Interface for more information). The CLI options are described in the sections below.

hashtag
Creating Compliance Report Definitions

It is possible to create several named compliance report definitions. Each named report defines the devices, services, and/or templates that should be part of the network configuration verification.

Let us walk through a simple compliance report definition. This example is based on the examples.ncs/service-management/mpls-vpn-javaarrow-up-right example. For the details of the included services and devices in this example, see the README file.

Each report definition has a name and can specify device and service checks. Device checks are further classified into sync and configuration checks. Device sync checks verify the in-sync status of the devices included in the report, while device configuration checks verify individual device configuration against a compliance template (see Device Configuration Checks).

For device checks, you can select the devices to be checked in four different ways:

  • all-devices - Check all defined devices.

  • device-group - Specified list of device groups.

  • device - Specified list of devices.

  • select-devices - Specified by an XPath expression.

Consider the following example report definition named gold-check:

This report definition, when executed, checks whether all devices known to NSO are in sync.

For such a check, the behavior of the verification can be specified:

  • To request a check-sync action to verify that the device is currently in sync. This behavior is controlled by the leaf current-out-of-sync (default true).

  • To scan the commit log (i.e. rollback files) for changes on the devices and report these. This behavior is controlled by the leaf historic-changes (default true).

For the example gold-check, you can also use service checks. This type of check verifies if the specified service instances are in sync, that is if the network devices contain configuration as defined by these services. You can select the services to be checked in four different ways:

  • all-services - Check all known service instances.

  • service - Specified list of service instances.

  • select-services - Specified list of service instances through an XPath expression.

  • service-type - Specified list of service types.

For service checks, the verification behavior can be specified as well:

  • To request a check-sync action to verify that the service is currently in sync. This behavior is controlled by the leaf current-out-of-sync (default true).

  • To scan the commit log (i.e., rollback files) for changes on the services and report these. This behavior is controlled by the leaf historic-changes (default true).

In the example report, you might choose the default behavior and check all instances of the l3vpn service:

You can also use the web UI to define compliance reports. See the section Compliance Reporting for more information.

hashtag
Running Compliance Reports

Compliance reporting is a read-only operation. When running a compliance report, the result is stored in a file located in a sub-directory compliance-reports under the NSO state directory. NSO has operational data for managing this report storage which makes it possible to list existing reports.

Here is an example of such a report listing:

There is also a remove action to remove report results (and the corresponding file):

When running the report, there are a number of parameters that can be specified with the specific run action.

The parameters that are possible to specify for a report run action are:

  • title: The title in the resulting report.

  • from: The date and time from which the report should start the information gathering. If not set, the oldest available information is implied.

  • to: The date and time when the information gathering should stop. If not set, the current date and time are implied. If set, no new check-syncs of devices and/or services will be attempted.

  • outformat: One of the formats from xml, html, text, or sqlite. If xml is specified, the report will be formatted using the DocBook schema. The generated file can be downloaded, for example, using standard CLI tools like curl or using Python requests via the URL returned by NSO.

We will request a report run with a title and formatted as text.

In the above command, the report was run without a from or a to argument. This implies that historical information gathering will be based on all available information. This includes information gathered from rollback files.

When a from argument is supplied to a compliance report run action, this implies that only historical information younger than the from date and time is checked.

When a to argument is supplied, this implies that historical information will be gathered for all logged information up to the date and time of the to argument.

The from and a to arguments can be combined to specify a fixed historic time interval.

When a compliance report is run, the action will respond with a flag indicating if any discrepancies were found. Also, it reports how many devices and services have been verified in total by the report.

Below is an example of a compliance report result (in text format):

hashtag
Downloading Compliance Reports

NSO generates a report file and returns a location URL pointing to it after running a compliance report using the command compliance reports <report-name> run outformat <format> . This URL is a direct HTTP(S) link to the report, which can be downloaded, for example, using a standard tool like curl or using Python requests. With basic authentication, the tools authenticate with NSO using a username and password, and allow users to retrieve and save the report file locally for further processing, automation, or archiving. You must first establish a JSON-RPC session before downloading the report. If the connection is closed before requesting the file, as is typically done with curl, use the returned session cookie to download the report.

The examples below clarify how to make requests.

Session-based authentication using the provided cookie to identify the session

hashtag
Device Configuration Checks

Services are the preferred way to manage device configuration in NSO as they provide numerous benefits (see Why services? in Development). However, on your journey to full automation, perhaps you only use NSO to configure a subset of all the services (configuration) on the devices. In this case, you can still perform generic configuration validation on other parts with the help of device configuration checks.

Often, each device will have a somewhat different configuration, such as its own set of IP addresses, which makes checking against a static template impossible. For this reason, NSO supports compliance templates.

These templates are similar to but separate from, device templates. With compliance templates, you use regular expressions to check compliance, instead of simple fixed values. You can also define and reference variables that get their values when a report is run. All selected devices are then checked against the compliance template and the differences (if any) are reported as a compliance violation.

You can create a compliance template from scratch. For example, to check that the router uses only internal DNS servers from the 10.0.0.0/8 range, you might create a compliance template such as:

Here, the value of the /sys/dns/server must start with 10., followed by any string (the regular expression .+). Since a dot has a special meaning with regular expressions (any character), it must be escaped with a backslash to match only the actual dot character. But note the required multiple escaping (\\\\) in this case.

As these expressions can be non-trivial to construct, the templates have a check command that allows you to quickly check compliance for a set of devices, which is a great development aid.

To simplify template creation, NSO features the /compliance/create-template action that can initiate a compliance template from a set of device configurations or an existing device template. The resulting template can be used as-is or as a starting point for further refinement. For example:

In addition to extracting patterns from configuration already present in NSO or from an existing device template, the action can also consume configuration snippets directly. Snippets can be supplied either from a file on the NSO server filesystem or as inline payload data. Supported formats are NETCONF-style XML wrapped in a <config> element, Cisco XR style CLI (cli-c), Juniper curly-brace CLI (cli-j), and Juniper set commands (cli-j-cmd). Delete operations in the input, such as Cisco-style no commands or XML operation="remove" attributes, are translated into absent tags in the generated compliance template.

By providing a list of device configuration paths, the create-template action can find common structural patterns in the device configurations and create a compliance template based on it.

The algorithm works by traversing the data depth-first, keeping track of the rate of occurrence of configuration nodes, and any values that compare equal. Values that do not compare equal are made into regex match-all expressions. For example:

The action takes a number of arguments to control how the resulting template looks:

  • path - A list of XPath 1.0 expressions pointing into /devices/device/config to create the template from. The template is only created from the paths that are common in the node-set.

  • match-rate - Device configuration is included in the resulting template based on the rate of occurrence given by this setting.

  • exclude-service-config - Exclude configuration that is already under service management.

  • collapse-list-keys - Decides what lists to do matching on, either all, automatic (default), or those specified by the list-path parameter. The default is to find those lists that differ among the device configurations.

Finally, to use compliance templates in a report, reference them from device-check/template:

circle-info

By default the schemas for compliance templates are not accessible from application client libraries such as MAAPI. This reduces the memory usage for large device data models. The schema can be made accessible with the /ncs-config/enable-client-template-schemas setting in ncs.conf.

hashtag
Device Live-Status Checks

In addition to configuration, compliance templates can also check for operational data. This can be used, for example, to check device interface statuses and device software versions.

This feature is opt-in and requires the NEDs to be re-compiled with the --ncs-with-operational-compliance ncsc(1) flag. Instructions on how to re-compile a NED is included in each NED package.

When running a check against a device, the result will show a violation if the status of the interface link is not up.

circle-info

Running checks on live-status data is slower than configuration data since it requires connecting to devices to read the data. In comparison, configuration data is checked against data in CDB.

hashtag
Additional Template Functionality

In some cases, it is insufficient to only check that the required configuration is present, as other configurations on the device can interfere with the desired functionality. For example, a service may configure a routing table entry for the 198.51.100.0/24 network. If someone also configures a more specific entry, say 198.51.100.0/28, that entry will take precedence and may interfere with the way the service requires the traffic to be routed. In effect, this additional configuration can render the service inoperable.

hashtag
strict Checks

To help operators ensure there is no such extraneous configuration on the managed devices, the compliance reporting feature supports the so-called strict mode. This mode not only checks whether the required configuration is present but also reports any configuration present on the device that is not part of the template.

You can configure this mode in the report definition, when specifying the device template to check against, for example:

Consider the following template and device configuration:

The device will be compliant with a regular template check. When using strict, all unexpected configuration will be shown in the diff.

hashtag
strict Sub-Tree Tag

In the previous example, the strict check shows interfaces that are not mentioned explicitly in the template. This is because strict is applied to the entire tree, including everything under interface. In order to only have strict on certain parts of the tree, a tag can be used.

After adding the strict tag to interface GigabitEthernet, running the check will result in a strict check against everything below GigabitEthernet.

hashtag
allow-empty Tag

A compliance template can be used on many different devices. The configuration on the devices, however, is not always identical. The following template checks that interfaces are set to be reachable.

The device in this example only has a GigabitEthernet interface which will result in a violation.

In this case, we are only interested in interfaces that are actually configured on the device. This is where the allow-empty tag comes in. By setting this tag on each interface, the check will only be run if there are interfaces configured of that type.

With this tag, the device will no longer have any violations.

It will still result in violations if the configuration is incorrect, but not if it's empty.

hashtag
absent Tag

In order to ensure that configuration does not exist on a device, the absent tag can be used.

This template will result in a violation if service finger is configured on the device.

hashtag
XML Compliance Templates

In addition to CDB-based compliance templates (configured under /compliance/template), NSO supports XML compliance templates: standalone .xml files that are loaded from the file system at startup, in the same way service templates are loaded. This makes it possible to version-control compliance checks alongside service templates and ship them as part of a package.

hashtag
XML Template File Format

An XML compliance template is an .xml file whose root element is <compliance-template> with the namespace http://tail-f.com/ns/config/1.0. The name attribute gives the template its unique name:

Values in the template are treated as regular expressions, and variables use the {$VAR_NAME} syntax and are substituted at check time.

hashtag
Loading XML Compliance Templates

Via ncs.conf (file-system directories)

Add one or more directory paths to /ncs-config/load-path/templates-dir/compliance in ncs.conf:

NSO scans each configured directory recursively for .xml files at startup and loads them as compliance templates.

Via packages

XML compliance templates can be placed in the templates/ subdirectory of a package alongside service templates. NSO automatically discovers and loads compliance templates from packages when they are loaded. Templates provided by a package are listed under /packages/package/compliance-templates.

hashtag
Processing Instructions

XML compliance templates support all processing instructions available for service templates, except for, foreach, and copy-tree. The supported instructions are:

Instruction
Description

<?if {xpath-expr}?> … <?else?> … <?end?>

Conditionally check parts of the template

<?set var = {xpath-expr}?>

Assign a variable

<?if-ned-id ned-id?> … <?end?>

Conditionally check based on the NED ID

<?macro name args?> … <?endmacro?>

Define a reusable template fragment

<?expand macro-name args?>

Expand a macro

hashtag
<?assert?> Processing Instruction

The assert instruction is new and specific to XML compliance templates. It evaluates an XPath boolean expression and, if the expression evaluates to false, records a failure with the provided error message. Failed assertions are returned in the output of the check action.

Syntax:

For example, to assert that exactly two ethernet interfaces exist on a device:

When an assertion fails, the check action output includes a failed-assertions list containing the location, context, and message of each failure.

hashtag
Inspecting Loaded XML Compliance Templates

All loaded XML compliance templates are visible under /compliance/xml-templates/template:

Each entry shows the template name, filename (path on disk), package (empty for templates loaded from the load-path rather than a package), and the list of variables used in the template.

Any loading errors — such as duplicate template names, malformed XML, or unsupported processing instructions — are reported in /compliance/xml-templates/error-info:

hashtag
Running a Compliance Check Against an XML Template

Use the check action under /compliance/xml-templates, supplying the template name and the target devices:

You can also target all devices or a device group:

When the template uses assert instructions, any failures appear in a failed-assertions list within the check result:

hashtag
Reloading XML Compliance Templates

To reload all templates (both from the load-path and from packages), use:

To reload only the templates loaded from the load-path (i.e., not from packages), use the dedicated reload action:

circle-info

As of NSO 6.7, XML compliance templates cannot be configured in compliance reports. Support for referencing XML templates from compliance report definitions (via device-check/xml-template) is planned for the next maintenance release.

hashtag
Re-run existing compliance report results

When a compliance report result includes violations, you typically want to run that compliance report again after fixing the violations. What if you could run only the violating items from the old report results again, skipping everything else?

Re-running only the violating items is possible by using the /compliance/report-results/report/re-run action.

hashtag
Example of re-run

First, we produce a compliance report result. This example assumes that you already know how to create compliance reports. Here, we use a compliance report called scale-test.

We now inspect this compliance report result and find what causes these violations. Maybe some leaf values are incorrectly configured, maybe services are out of sync. There are six violations in this run, on two devices and four services.

We re-run the report result and notice that only the devices and services involved in violations are now part of the new re-run report result.

We fix these violations, and re-run the compliance report based on the new report result.

Note that compliance-status is now no-violation. We have managed to fix all violations and we did not need to re-run the full compliance report in order to achieve this. This saves time and makes the resulting report smaller and easier to read.

If we re-run the successful report result, we see that this final re-run does not include any devices nor any services.

hashtag
Renamed devices and removed services

The /compliance/report-results/report/re-run action will ignore any renamed devices and removed services, these will be dropped from the resulting new compliance report result.

PreviousPlug-and-Play ScriptingNextListing Packages

Last updated

Was this helpful?