CNC tsdn-core-fp-common alarms purge and NSO CLI alarms: When we re-deploy a TSDN CFP RSVP-TE service and the configuration is rejected by the device I see and "service-activation-failure" alarm in the NSO CLIncsadmin@ncs-ts4nso01vs001# te tunnels tunnel pcepadap10496 re-deployError: External error in the NED implementation for device WSBMPS11: command: path: Error: String too longncsadmin@ncs-ts4nso01vs001# *** ALARM service-activation-failure: External error in the NED implementation for device WSBMPS11: command: path: Error: String too longncsadmin@ncs-ts4nso01vs001# but this alarm is no longer present in the alarm list:ncsadmin@ncs-ts4nso01vs001# show alarms alarm-listalarms alarm-list number-of-alarms 0This alarm is actually removed by tsdn-core-fp-common. Why does this happen?<INFO> 22-Jun-2022::11:46:52.392 cisco-tsdn-core-fp-common Thread-9: - Received alarm: /te:te/tunnels/tunnel<DEBUG> 22-Jun-2022::11:46:52.394 cisco-tsdn-core-fp-common Thread-9: - alarm text: External error in the NED implementation for device WSBMPS11: command: path: Error: String too long<DEBUG> 22-Jun-2022::11:46:52.412 cisco-tsdn-core-fp-common : - CQ Alarms received: {'cq_alarms': []}<DEBUG> 22-Jun-2022::11:46:52.413 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 22-Jun-2022::11:46:52.414 cisco-tsdn-core-fp-common : - Service alarms: {'service_alarms': []}<DEBUG> 22-Jun-2022::11:46:52.414 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 22-Jun-2022::11:46:52.414 cisco-tsdn-core-fp-common Thread-9: - Purged alarm: /te:te/tunnels/tunnelI'm struggling to explain to Vodafone this "ghost" alarms displayed in the CLI.Context:1) Vodafone Germany wants to test the SNMP alarm notifications originating from NSO, going into their alarm monitoring system named Spectrum. One of the alarms when want to see is: ALARM service-activation-failure2) Im not using CQ3) Im using the RSVP-TE TSDN CFPThis is how Im generating this alarm in the Vodafone Germany Lab:Package is loaded correctly and service is created correctly.No alarms present in NSO.ncsadmin@ncs-ts4nso01vs001#ncsadmin@ncs-ts4nso01vs001# te tunnels tunnel pcepadap10496 deep-check-syncsync-result {  local-node {    in-sync true  }}ncsadmin@ncs-ts4nso01vs001# show alarms alarm-list number-of-alarmsalarms alarm-list number-of-alarms 0</ul>I make a change in the NSO service device template, making a string longer that what the device will accept.This will cause the device to reject the config with an error: string too longPerform a packages reload.</ul>Perform a service re-deploy that will fail with String too long:I can see the alarm ALARM service-activation-failure appearing in all open NSO CLI terminalsI can see it being deleted in the cisco-tsdn-core-fp-common log.</ul>ncsadmin@ncs-ts4nso01vs001# show alarms alarm-list number-of-alarmsalarms alarm-list number-of-alarms 0ncsadmin@ncs-ts4nso01vs001# te tunnels tunnel pcepadap10496 re-deployError: External error in the NED implementation for device WSBMPS11: command: path: Error: String too longncsadmin@ncs-ts4nso01vs001# *** ALARM service-activation-failure: External error in the NED implementation for device WSBMPS11: command: path: Error: String too longncsadmin@ncs-ts4nso01vs001#System message at 2022-06-23 13:00:45...Commit performed by ncsadmin via ssh using cli.ncsadmin@ncs-ts4nso01vs001#ncsadmin@ncs-ts4nso01vs001#ncsadmin@ncs-ts4nso01vs001#ncsadmin@ncs-ts4nso01vs001# show alarms alarm-list number-of-alarmsalarms alarm-list number-of-alarms 0ncsadmin@ncs-ts4nso01vs001#ncsadmin@ncs-ts4nso01vs001#<DEBUG> 23-Jun-2022::13:00:45.213 cisco-tsdn-core-fp-common : - CQ Alarms received: {'cq_alarms': []}<DEBUG> 23-Jun-2022::13:00:45.213 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 23-Jun-2022::13:00:45.214 cisco-tsdn-core-fp-common : - Service alarms: {'service_alarms': [('ncs', 'service-activation-failure', '/te:te/tunnels/tunnel[name="pcepadap10496"]', '')]}<DEBUG> 23-Jun-2022::13:00:45.214 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 23-Jun-2022::13:00:45.222 cisco-tsdn-core-fp-common Thread-9: - Received alarm: /te:te/tunnels/tunnel<DEBUG> 23-Jun-2022::13:00:45.224 cisco-tsdn-core-fp-common Thread-9: - alarm text: External error in the NED implementation for device WSBMPS11: command: path: Error: String too long<DEBUG> 23-Jun-2022::13:00:45.246 cisco-tsdn-core-fp-common : - CQ Alarms received: {'cq_alarms': []}<DEBUG> 23-Jun-2022::13:00:45.246 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 23-Jun-2022::13:00:45.247 cisco-tsdn-core-fp-common : - Service alarms: {'service_alarms': []}<DEBUG> 23-Jun-2022::13:00:45.247 cisco-tsdn-core-fp-common : - Waiting for subscription event<INFO> 23-Jun-2022::13:00:45.247 cisco-tsdn-core-fp-common Thread-9: - Purged alarm: /te:te/tunnels/tunnelWhen the ALARM service-activation-failure is created in NSO, the SNMP Notification is sent to Spectrum.The Vodafone operations team monitoring Spectrum sees the alarm and will go to NSO to perform an investigation and eventually mark the alarm cleared but no alarm is present in NSO.ncsadmin@ncs-ts4nso01vs001# show alarms alarm-list number-of-alarmsalarms alarm-list number-of-alarms 0ncsadmin@ncs-ts4nso01vs001# show alarms alarm-list number-of-alarmsalarms alarm-list number-of-alarms 0a) I need to explain the above behaviour to Vodafone in the context of how should the operational team act facing this alarm.B) In the NSO admin guide it is written:Alarm Identity: service-activation-failureClear condition(s): If the service is successfully redeployed, the alarm is cleared.but Vodafone will not have this alarm in NSO.
Hi Sujay,For TSDN, I believe this has been the behavior for service alarms. tsdn-core-fp-common code purges the alarm which is then reflected on the plan state marked failed with the exact alarm text. This applicable to all the services.This failure will be sent in plan notification.ThanksSahithiExpected behavior from CFP. Delete alarms are purged as we want NSO to recreate the same alarms on re-deploy.