Compliance Reporting

When the unexpected happens or things come to the worst and the network configuration is broken, there is a need to gather information and verify the configuration.

NSO has numerous functions to show different aspects of such a network config verification. However, to simplify this task, the compliance reporting can assemble information using a selection of these NSO functions and present the resulting information in one report. The aim for this report is to answer two fundamental questions:

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. But it does not stop here. Compliance reporting can also be based on one or a number of stored device templates which the live devices are compared against. The compliance reports can also be a combination of both approaches.

Compliance verification can be defined to check the current situation or checking historic events, or both. To assemble historic events, rollback files and audit logs are used. Therefore these functionalities must have been enabled for the time period of interest, or else no history view can be presented.

The reports can be formatted either as text, html or docbook xml format. The intention of the docbook format is that the user can take the report and by further post-processing create reports formatted by own choice, for instance PDF using Apache FOP.

It is possible to create several named compliance report definitions. Each named report defines which devices, services and/or templates that the configuration should be checked for.

The CLI command below shows a very simple definition (if you start the examples.ncs/service-provider/mpls-vpn you will see this example):

ncs(config)# show full-configuration compliance
compliance reports report Compliance-Audit
 device-check all-devices
 device-check current-out-of-sync true
 device-check historic-changes true
 device-check historic-out-of-sync true
 service-check all-services
 service-check current-out-of-sync true
 service-check historic-changes true
 service-check historic-out-of-sync true
 compare-template snmp1 P
  variable COMMUNITY
   value 'public'
  !
 !
 compare-template snmp1 PE
  variable COMMUNITY
   value 'public'
  !
 !
!

This definition says that the "Compliance-Audit" audit will do a check-sync for all devices and services when the report is executed. It also includes historical entries from the NSO audit log indicating that the same devices and services have been out of sync.

The report also specifies that the template named snmp1 shall be compared with all devices in the device-group called P using the template variable value "COMMUNITY=public".

A named report can be executed and takes the following parameters when run:

So the report defined above, daily-audit can be executed with:

ncs(config)# compliance reports report Compliance-Audit run
       from 2014-09-01T00:00:00 title "ISO check" outformat html
id 1
compliance-status violations
info Checking 17 devices and 2 services
location http://localhost:8080/compliance-reports/report_1_admin_1_2014-9-14T15:10:21:0.html

As seen above the report found compliance violations.

The contents of the report is:

Some examples are given below. First we see a report snippet that illustrates that NSO has detected that the device ce0 and the volvo VPN has been out of sync:

Figure 6. Service out of sync, and template discrepancies

The other example shows a summary of all commits. Note that a habit of using labels and commits makes the reports more useful. Also a summary of every commit for the specified devices and services are included in the report.

Figure 7. Commit history

All report runs are saved in a table and the report itself on disc.