Event Notification

A NetConf client registers to receive event notifications from a NetConf server by creating a subscription. The NetConf server begins notifications as events occur within the system if the subscription is successful. These event notifications will continue to be sent until either the NetConf session is terminated or the subscription terminates for some other reason.

There are four types of events supported in NetConf:

1. netconf-config-change.
2. netconf-capability-change.
3. netconf-session-start.
4. netconf-session-end.

By default the notification will not be received by the client unless the client is not subscribed.

Notifications for Operational Status

Event notifications are sent for operational status, when the following events occur:

• Service status changes from operational -> non-operational (no flow of traffic)
• Service status changes from non-operational -> operational (flow of traffic)

A NetConf subscription to receive notifications must be done on the controller.

Once the NetConf session is established between the controller and leaf, the NetConf RPC start-service-tracking is invoked with details of the service to be tracked.

Also, a NetConf event notification and an SNMP Trap are sent when an image upgrade initiated by the controller is completed successfully.

The controller invokes NetConf RPC sys-update-get to download the image. The node sends the notification sys-update-download-status when the download finishes.

For the SNMP trap, the controller invokes NetConf RPC start-service-tracking with details of service to be tracked and edits the configuration to restore traffic in the node. NSM periodically checks for all the established traffic flows, using traffic rates and interfaces status. When all the required conditions match, the send-service-tracking-status notification is sent out.

NETCONF Notification Subscription

To subscribe to a notification as per RFC 5277, a NetConf client should send the create-subscription RPC.

Basic Subscription

To receive all notifications from the default NetConf stream:

Copy 
yangcli ocnos@0> create-subscription

RPC OK Reply 1 for session 1:

Enhanced Subscription Filtering (Severity, Event Class, Stream)

CML (OCNOS) enhances the basic subscription model by supporting fine-grained filters based on following parameters:

• Severity levels (info, warning, minor, major, critical)
• Event classes (config, state, message)
• Stream name (default: NetConf)

• Filtering is supported using the filter and stream options in create-subscription.
• Replay features <startTime>, <stopTime> are not supported in create-subscription.

Event Classes and Applicable Notifications

Event Class Applicable Notifications
config CML_OBJECT_CREATE_NOTIF, CML_OBJECT_DELETE_NOTIF, CML_ATTRIBUTE_VALUE_CHANGE_NOTIF
state CML_STATE_CHANGE_NOTIF
message CML_ALARM_MESSAGE_NOTIF, CML_EVENT_MSG_NOTIF

Severity & Event Class Filter

To receive only critical state change notifications, user must provide a filter XML:

Example of XML File (notification_filter.xml)

Copy 
<notification>
  <severity>critical</severity>
  <eventClass>state</eventClass>
</notification>

Example of Yangcli:

Copy 
yangcli ocnos@0> create-subscription filter=@/home/xml/notification_filter.xml

RPC OK Reply 1 for session 5:

Stream Filter

To explicitly specify a stream, By default, the NETCONF stream is used:

Currently SNMP and SYSLOG streams are not supported.

Copy 
yangcli ocnos@0> create-subscription stream=NETCONF

RPC OK Reply 1 for session 6:

Example of combined Stream + Filter

User can combine both stream and filter in one subscription:

Copy 
yangcli ocnos@0> create-subscription stream=NETCONF
filter=@/home/xml/notification_filter.xml

Example of RPC (with filter)

Copy 
<netconf:rpc message-id="101"
    xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
  <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <filter netconf:type="subtree">
      <notification>
        <severity>critical</severity>
        <eventClass>state</eventClass>
      </notification>
    </filter>
  </create-subscription>
</netconf:rpc>

Summary

Feature Support Details
Basic subscription Supported
Stream filtering Supported (NetConf only)
Severity filtering Supported
Event class filter Supported
Replay (start/stop) Not supported

netconf-config-change

This notification is generated when the NetConf server detects that the <running> configuration data store has been changed by a management session. The notification summarizes the edits performed on the above mentioned data stores.

Steps to receive config change notification:

1. Create NetConf notification subscription (command: create-subscription). By default this will also subscribed for config-change notification.
2. Perform any of the following operations
• Create
• Merge
• Delete
• Replace
3. Do commit
4. Config change notification will be received.
5. Config change notification can be disabled for current session. (command: config-change-subscription status=disable)
6. Someone can check whether current session has been subscribed for config change notificaion. (command: show-config-change-subscription)


• Config-change notification will be generated for the creation, deletion, or update of only non-leaf nodes (i.e. container, list) of YANG model.
• If a leaf node is being set or unset, indicating a modification of parent non-leaf nodes (i.e., container, list), in this case, a configuration change notification will be generated for the parent non-leaf nodes (i.e., container, list) with the operation set as 'merge'.

Example

1. Create Yangcli session
2. Subscribe for notification
Copy 
yangcli root@0> create-subscription
    RPC OK Reply 4 for session 1
By default, this will also subscribed for config-change notification.
3. Someone can check whether current session has been subscribed for config change notification
Copy 
    yangcli root@0> show-config-change-subscription
    RPC Data Reply 6 for session 1:
    <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <status xmlns="http://ipinfusion.com/ns/zebmcli">ENABLED</status>
    </rpc-reply>
4. Do some configuration
Copy 
(config)#interface eth3
    (config-if)#shut
    (config-if)#commit
    Config-change notification will be received
5. Config change notification will be received
Copy 
    yangcli root@0>

Incoming notification:

Copy 
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2021-11-29T10:02:45Z</eventTime>
    <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <changed-by>
    <username>root</username>
    <session-id>0</session-id>
    </changed-by>
    <datastore>running</datastore>
    <edit>
    <target>/interfaces/interface[name='eth3']/config</target>
    <operation>merge</operation>
    </edit>
    </netconf-config-change>
    </notification>

netconf-capability-change

This notification is generated when the NetConf server detects that the <running> or <startup> configuration data store has been changed by a management session. The notification summarizes the edits performed on the above mentioned data stores.

Currently this kind of event notification is not supported.

Copy 
notification {
    eventTime 2017-10-24T12:23:42Z
    sysCapabilityChange {
        changed-by {
            userName root
            sessionId 1
            remoteHost 127.0.0.1
    }
    added-capability http://netconfcentral.org/ns/toaster?module=toaster&revision=2009-11-20
    }
}

netconf-session-start

This notification is generated when a NetConf server detects client session start. Information present in this notification indicates the identity of the user.

Copy 
notification {
    eventTime 2019-03-09T08:16:20Z
    severity info
    eventClass message
    sysSessionStart {
        sessionId 6
        remoteHost 10.12.47.71
    }
}

netconf-session-end

This notification is generated when a NetConf server detects client session termination. Information present in this notification indicates the identity of the user that owned the session, and why the session was terminated.

Copy 
notification {
    eventTime 2019-03-09T08:18:55Z
    severity info
    eventClass message
    sysSessionEnd {
        userName ocnos
        sessionId 7
        remoteHost 10.12.47.71
        terminationReason closed
    }
}
 
notification {
    eventTime 2019-03-09T08:19:36Z
    severity info
    eventClass message
    sysSessionEnd {
        userName ocnos
        sessionId 8
        remoteHost 10.12.47.71
        killedBy 5
        terminationReason killed
    }
}

Notification Cache Support in CML

The CML framework supports notification cache functionality. By default this feature is disabled, it can be enabled through configuration.

Behavior of the feature when enabled:

• When the device is reloaded or the system is upgraded, CML stores notifications in the cache.
• Notifications are stored up to max-cache-notifications (default: 100) and for a duration defined by cache-period (default: 20 minutes).
• If a NETCONF session is established and subscribes to notifications within the cache period, CML delivers all cached notifications to that session and then clears the cache.
• If no NETCONF session subscribes within the cache period, the cached notifications are discarded.

Priority-based Caching:

A special tag <cachePriority> can be included in data-model to override default behavior.

Example

Copy 
<notification>
        name="bgnos-image-upgrade-done"
        desc="This belugaNOS update event is generated when the OS boots with sucess after a system upgrade operation.">
        <type>CML_ALARM_MESSAGE_NOTIF</type>
        <subType>NB_NETCONF</subType>
        <cachePriority>HIGH</cachePriority>
        <severity>INFO</severity>
    </notification>

If cachePriority is set to HIGH, the notification is always stored in the cache, regardless of the max-cache-notifications limit.

Please refer the document NETCONF Command Reference for notification cache configuration.