NCCM is a Network Management term that refers to configuration backups and stands for “Network Configuration and Change Management”. NetYCE has NCCM built-in and is part of all jobs executed on devices. A configuration snapshot is taken from the device when the job logs in on the device, and again when a configuration change is made.

Additionally, the NCCM can be configured to perform periodic polling of the devices to retrieve the current configuration and store it. And finally, starting with release 7.2, the devices can signal a configuration change by means of a syslog message resulting in a NCCM poll.

The NCCM can retrieve the configuration from the device when:

• A NetYCE job changes the configuration. Every job will retrieve the configuration before and after the change. Both configurations will be incorporated in the NCCM history of that device.
• The device sends a syslog message to the NetYCE server to inform of a configuration change. The configuration is then retrieved and appended to the NCCM history.
• The device is scheduled to have its configuration periodically fetched by the NCCM poller.

An operational NCCM is a prerequisite to use the NetYCE Compliance. Only devices with at least one entry in the NCCM can be validated using Compliance Policies. Please refer to the Compliance Overview for its use.

NetYCE refers to the NCCM as a repository of all historic configurations of a device within the time and storage limits set on it. To permit effective storage of this potentially vast amount of data a schema is used to store only occasionally the full configuration text and for each subsequent configuration only the differences. A set of policies control how often these base configurations must be made and how large the resulting differences.

The resulting schema allows for very fast retrieval of any configuration at a given time and being able to compare the differences between any two points in time. De default history of the NCCM is set at 800 days.

For details on the NCCM policies and settings, please refer to the Lookup NCCM tweaks. For reference on the NCCM database tables, please refer to the NCCM Reference.

Any historic configuration in the NCCM, or the very latest, can be restored to the device using jobs or manual download.

The NCCM can only work with configured nodes (devices) in NetYCE. There are two types of nodes it can work with.

Firstly the fully modelled NetYCE nodes that are created using Service-types based on Node-types, normally referred to as “YCE-nodes”.

Secondly nodes that are defined in the NetYCE CMDB, normally referred to as “CMDB-nodes”. These nodes can be added manually in the “Operate - CMDB” form or from an external source using the XCH API.

The NCCM uses “Polling Groups” to control for which nodes the NCCM is maintained. A Polling Group is a collection of nodes that use the same polling interval and polling-retries under a shared name. The nodes can be assigned to the Polling Group directly when its type is set to “Nodes”.

By entering node-names or node-name wildcards all matching nodes can be assigned directly the the Polling Group. And unwanted nodes can simply be removed from the list.

The “Nodes” type Polling Group has the benefit of a straightforward node name assignment but has the drawback of being static. That means that when a new CMDB-node or YCE-node is added it is not automatically included in the NCCM polling.

To achieve the dynamic inclusion of nodes in a Polling Group, its type must be set to “Node groups”. Now the operator can only select which Node Groups can be assigned to the Polling Group. Node Groups are a collection of nodes matching one or more criteria and are therefore dynamic in nature. New nodes are automatically included or excluded from the Polling group based on attributes like Client, Site, Vendor, Model, Name, etc. For more robust NCCM deployments the Node Group approach is recommended

Both the CMDB-nodes and the YCE-nodes rely on a “Domain” reference that should contain the login credentials for the node. Specifically the variables “Rme_user” and “Rme_password” and if applicable the “Default_enable_secret” are relevant. Without these details the NCCM cannot access the device to retrieve the configuration.

Additionally the CMDB-nodes need to have a valid IP-address to the node. This can be an IPv4, IPv6 or a FQDN (full-qualified domain name) that is DNS resolvable. For the YCE-nodes usually both are available.

The configuration is retrieved using the NetYCE vendor modules. The Vendor_type set in the YCE-node or CMDB-node must match that of the device and must be a supported vendor module. Mismatches will cause the sessions to fail.

As syslog messages from devices might not have their hostname included in the message, a means to resolve the included IP-address in its fqdn or hostname is then required. NetYCE NCCM relies on the reverse lookup capabilities of the resident DNS to provide the fqdn. When needed the /etc/hosts file of each NetYCE server could be used as a stop-gap solution.

To retrieve the configuration from the device the file is pushed (uploaded) from the device to the NetYCE server. The transfer method selected is dependent on the vendor-type and can be modified using the “Admin - Custom data” tool for the YCE table “Vendors”. The protocol in “Vendor_transfer” can be modified if needed.