README-ned-settings

NED settings details


This NED is equipped with a number of runtime configuration options "NED settings" allowing for customization by the end user. All options are configurable using the NSO API for NED settings. Most NED settings can be configured globally, per device profile or per device instance in the following locations:

global /ncs:devices/global-settings/ned-settings/cisco-iosxr_gnmi/ profile /ncs:devices/ncs:profiles/profile:/ned-settings/cisco-iosxr_gnmi/ device /ncs:/device/devices/device:/ned-settings/cisco-iosxr_gnmi/

Profiles setting overrides global-settings and device settings override profile settings, hence the narrowest scope of the setting is used by the device.

If user changes a ned-setting, then user must reconnect to the device, i.e. disconnect and connect in order for the new setting to take effect.

From the NSO CLI the device instance NED settings for this NED are available under:

# config
# devices device dev-1 ned-settings cisco-iosxr_gnmi

Press TAB to see all the NED settings.

Table of contents


1. ned-settings cisco-iosxr_gnmi
2. live-status
3. logger
4. connection
   4.1. keep-alive
   4.2. tls
        4.2.1. mutual-tls
5. gnmi
   5.1. origin
   5.2. inbound
   5.3. outbound
        5.3.1. confirmed-commit
   5.4. notif
        5.4.1. stream
   5.5. cache
6. general
   6.1. capabilities
        6.1.1. regex-exclude
        6.1.2. regex-include
        6.1.3. inject
   6.2. config
   6.3. live-status

1. ned-settings cisco-iosxr_gnmi


2. ned-settings cisco-iosxr_gnmi live-status


Settings for live-status.

3. ned-settings cisco-iosxr_gnmi logger


Settings for controlling logs output.

4. ned-settings cisco-iosxr_gnmi connection


Settings for the gNMI connection.

4.1. ned-settings cisco-iosxr_gnmi connection keep-alive


Connection keep alive settings.

4.2. ned-settings cisco-iosxr_gnmi connection tls


TLS authentication settings.

4.2.1. ned-settings cisco-iosxr_gnmi connection tls mutual-tls


Settings related to mTLS.

5. ned-settings cisco-iosxr_gnmi gnmi


Settings for the gNMI operations.

5.1. ned-settings cisco-iosxr_gnmi gnmi path origin


The origin is an optional message field to be used to disambiguate the gNMI path if necessary. Some devices require the origin to be set in all gNMI operations. One use case where origin can be extra relevant is when dealing with devices that support multiple different YANG model packages. For example native and openconfig. In this case the device might require the origin field in each gNMI to be set such that it maps to the YANG model package the operation maps to.

5.2. ned-settings cisco-iosxr_gnmi gnmi config inbound


Settings for customising the NED regarding inbound config data.

5.3. ned-settings cisco-iosxr_gnmi gnmi config outbound


Settings for customising the NED regarding outbound config data.

5.3.1. ned-settings cisco-iosxr_gnmi gnmi config outbound confirmed-commit


Confirmed commit is a new gNMI feature that makes it possible to tell the gNMI server to auto rollback the applied configuration after a certain duration. For example if a bad configuration was pushed. The feature is very similar to the corresponding in NETCONF (rfc6241).

5.4. ned-settings cisco-iosxr_gnmi gnmi notif


Configure notification streams available on the device.

5.4.1. ned-settings cisco-iosxr_gnmi gnmi notif stream


Manually configure custom streams on the device The gNMI protocol allows for subscribing on changes anywhere in the data tree.

5.5. ned-settings cisco-iosxr_gnmi gnmi cache


The NED is able to cache certain data that is typically probed for when a new connection is setup. Caching has good impact on performance, since it reduces the number of necessary round trips to the device on subsequent connections.

6. ned-settings cisco-iosxr_gnmi general


General NED settings.

6.1. ned-settings cisco-iosxr_gnmi general capabilities


Settings related to device capabilities.

6.1.1. ned-settings cisco-iosxr_gnmi general capabilities regex-exclude


Configure a pattern for matching models to exclude from the capabilities list advertised by the device. To be used to limit the scope of models registered into NSO by the NED.

6.1.2. ned-settings cisco-iosxr_gnmi general capabilities regex-include


Configure a pattern for matching models to include from the capabilities list advertised by the device. To be used to limit the scope of models registered into NSO by the NED.

6.1.3. ned-settings cisco-iosxr_gnmi general capabilities inject


Configure additional names of models to include in the capabilities list. If a device is not able to advertise any capability list, the names of the models to be used must be manually added to this inject list.

6.2. ned-settings cisco-iosxr_gnmi general config


General settings related to config handling.

6.3. ned-settings cisco-iosxr_gnmi general live-status


General settings related to live-status handling.

7. Using the NED to receive gNMI telemetry updates

The gNMI protocol has an advanced built-in method for subscribing on telemetry updates from a device. This feature is fully supported by Cisco IOSXR gNMI devices.

It is a very flexible feature regarding what kind of events to subscribe on. The gNMI specification allows for subscriptions on events anywhere in the data tree of a device. You can subscribe on config changes and/or operational data.

The nodes to subscribe on are specified using a list of xpaths that points to the nodes. A xpath can point to a single leaf, a subtree or a full tree.

This NED has full support for receiving telemetry subscriptions. Each received event is relayed into the standard NSO API for notifications as usual.

There are however limitations regarding how NSO can handle this kind of events.

The NSO API for notifications is designed to be compliant with NETCONF notifications (RFC5277) which makes it partly incompatible with gNMI events.

Hence a few additional steps are required to make this work with NSO:

  1. The NSO API does require streams to subscribe on. These streams are expected to be advertised by the device which is not possible with gNMI. Instead the NED provides a simple method to configure virtual streams that NSO can subscribe on. These streams will be advertised by the NED instead.

  2. The NSO API expects each received notification to be of a well defined structure as declared in a 'notification' YANG construct. This is not compliant with gNMI where a telemety update can contain data of any structure. The data is simply a JSON/XML dump representing the nodes that are being subscribed on.

The NED bridges these incompatible concepts by using an internal 'notification' YANG construct, shown below:

For telemetry updates the payload in the received gNMI event is simply inserted as a raw JSON/XML snippet into a notification message before it is relayed to NSO. Telemetry deletes are similarly relayed to NSO as a list of xpaths. Each xpath represents a node that has been deleted on the device.

This means that the data in the notification will be delivered unparsed to any listening service application. It is up to the service application to parse it before acting upon it.

Example:

The use case is to configure a virtual stream that will subscribe on interface events on the gNMI device. This example is using the xpaths as defined by the Cisco IOSXR models.

  1. Configure the virtual stream using the NED settings in the device instance, like below in a NSO CLI:

  2. Try letting NSO display information about available streams

  3. Configure a subscription on the stream named INTERFACE-EVENTS

    Note, the configuration parameter 'store-in-cdb' is set to true in this example just to make sure the received telemetry updates can be displayed properly in step #5 and #6 below. This parameter shall usually be used with caution, since it can have impact on CDB performance and size.

  4. Verify that the subscription is now active in NSO

  5. Trigger a telemetry update notification by configuring an interface

    A new entry in the list shall now exist containing a JSON formatted string in the 'updates' leaf:

TBD

Last updated

Was this helpful?