NCS and SNMP Trap triggers

[khgrant]

Hi NCS giants,

I’m reviewing a possible application with a client.  The application relies on an SNMP trap coming from a CMTS to trigger NCS. Upon receipt of the trap, NCS will look up a PW ID in the CDB and create a service in an ASR9K

Question: does NCS need to have the CMTS under management (i.e. synced) to receive and react to traps from that device?

Of course, the CMTS would need to be configured to forward traps to NCS.  But does NCS need to have the CMTS in its database to recognize and react to the trap?

Thanks

Ron Whitt

[khgrant · Accepted solution]

No it does not need to be managed by NCS to receive traps.

-Dan

[khgrant]

There are more details in chapter 10 on this in ncs_development-3.4.1 guide.

Thanks,

Ajay

[khgrant]

I am confused by the following statement in the ncs_development.pdf and what has been stated:

Configuring NCS to Receive SNMP Notifications

The NCS operator must enable the SNMP notification receiver, and configure the addresses NCS will use to listen for notifications. The primary parameters for the Notification receiver are shown below.

+--rw snmp-notification-receiver

+--rw enabled? boolean

+--rw listen

| +--rw udp [ip port]

| +--rw ip inet:ip-address

| +--rw port inet:port-number

+--rw engine-id? snmp-engine-id

The notification reception can be turned on and off using the enabled lead. NCS will listen to notifications at the end-points configured in listen. There is no need to manually configure the NCS engine-id.

NCS will do this automatically based using the algorithm described in RFC 3411. However, it can be assigned an engine-id manually by setting this leaf.

The managed devices must also be configured to send notifications to the NCS addresses.

NCS silently ignores any notification received from unknown devices. By default, NCS uses the /devices/

device/address leaf, but this can be overridden by setting /devices/device/snmp-notification-address.

+--rw device [name]

| +--rw name string

| +--rw address inet:host

| +--rw snmp-notification-address? inet:host

How do I configure NCS to listen to traps from a device that is not managed by NCS?  Do I create the entry under /devices/device but not connect and sync to it (is this recommended)?

Thanks,
Johan

[khgrant]

The NCS operator must enable the SNMP notification receiver, and configure the addresses NCS will use to listen for notifications. The primary parameters for the Notification receiver are shown below.

+--rw snmp-notification-receiver

+--rw enabled? boolean

+--rw listen

| +--rw udp [ip port]

| +--rw ip inet:ip-address

| +--rw port inet:port-number

+--rw engine-id? snmp-engine-id

The notification reception can be turned on and off using the enabled lead. NCS will listen to notifications at the end-points configured in listen. There is no need to manually configure the NCS engine-id.

NCS will do this automatically based using the algorithm described in RFC 3411. However, it can be assigned an engine-id manually by setting this leaf. The managed devices must also be configured to send notifications to the NCS addresses.

NCS silently ignores any notification received from unknown devices.By default, NCS uses the /devices/

device/address leaf, but this can be overridden by setting /devices/device/snmp-notification-address.

+--rw device [name]

| +--rw name string

| +--rw address inet:host

| +--rw snmp-notification-address? inet:host

How do I configure NCS to listen to traps from a device that is not managed by NCS?  Do I create the entry under /devices/device but not connect and sync to it (is this recommended)?

Yes, you need to have the device defined. However it can be in admin state locked (or southbound-locked) to prevent any operations on that device.

See the examples.ncs/snmp-notification-receiver which defines one device but has no Ned for that device.

/Try