Showing results for 
Search instead for 
Did you mean: 

Troubleshooting nano services in PnP Core Function Pack


I'm trying to deploy and test NSO Cisco PnP Core Function Pack 3.0.2. I installed confd and two NSO packages pnp-service-3.0.2 and confd-pnp-ned-nc-1.0 on ncs-

Initial configuration has been done per documentation.
Map configuration for the test router is shown below:




pnp map 9I0AZUN0V9J
 serial 9I0AZUN0V9J 
 device-name R2-new
 authgroup default
 username admin 
 password $8$1qT9UhUf5GmxYhM5uvoAgPT4tqqgmu5+Hw5WPaQSYx4=
 sec-password $8$2CT7UuvNwAfm7WblGu6tlpUe7dAAd1cMGEhl2zu9mwY= 
 device-type cli
 ned-id cisco-ios-cli-6.67 
 port 22
 day0 day0-file [ CSR1000v.txt ]
 day0 cfg-properties variable CSR_HOSTNAME
 value R2-clean16
 managed true




Router contacts confd (using DHCP option 43), gets day0 config but it is never added to the NSO as managed device.
PnP is implemented as nano service in NSO and device is stuck in the device-created with create-init post action state.
Documentations says "If the action is still executing, then the leaf will show either a create-init or delete-init status instead." which means something got stuck.





admin@ncs# show pnp map-plan
                             BACK                                                                  POST ACTION  
TYPE            NAME         TRACK  GOAL  STATE             STATUS       WHEN                 ref  STATUS       
self            self         false  -     init              reached      2023-05-03T14:24:31  -    -            
                                          device-connected  reached      2023-05-03T14:24:31  -    -            
                                          ready             not-reached  -                    -    -            
managed-device  9I0AZUN0V9J  false  -     init              reached      2023-05-03T14:24:31  -    -            
                                          device-created    reached      2023-05-03T14:25:13  -    create-init  
                                          fetch-host-keys   not-reached  -                    -    -            
                                          sync              not-reached  -                    -    -            
                                          ready             not-reached  -                    -    -            




Examining the yang model there is pre-condition to monitor pnp state for particular serial and a trigger for "device-added" value and execute "pnp internal actions create-device"




ncs:component-type "ns-pnp:managed-device" {
      ncs:state "ncs:init";

      ncs:state "ns-pnp:device-created" {
        ncs:create {
          ncs:pre-condition {
              ncs:monitor "/pnp-service:pnp/pnp-service:state[serial=$SERIAL]" {
              // TODO: Is this always the case, i.e it's enough that we
              // see the device to send down the map config?
              ncs:trigger-expr "device-added";
          ncs:post-action-node "/pnp-service:pnp/pnp-service:internal/pnp-service:actions" {
            ncs:action-name "create-device";




The device clearly has state "device-added" as shown below. In the plan you can see that devices reached "device-created"  but the kicker never execute the post-action which should trigger class CreateDeviceAction(ncs.dp.Action) in the python and add device to the NSO. You can see create-init post action state like something got stuck.




admin@ncs# show pnp state 9I0AZUN0V9J | display xpath 
/pnp/state[serial='9I0AZUN0V9J']/udi PID:CSR1000V,VID:V00,SN:9I0AZUN0V9J
/pnp/state[serial='9I0AZUN0V9J']/device-info 16.3.6
/pnp/state[serial='9I0AZUN0V9J']/hostname R2-clean16
/pnp/state[serial='9I0AZUN0V9J']/port 22
/pnp/state[serial='9I0AZUN0V9J']/name 9I0AZUN0V9J
/pnp/state[serial='9I0AZUN0V9J']/discovery-created true
/pnp/state[serial='9I0AZUN0V9J']/server confdpnp
/pnp/state[serial='9I0AZUN0V9J']/claimed true
/pnp/state[serial='9I0AZUN0V9J']/latest-event-type device-added




If I manually run command bellow, device is added to the NSO.




pnp internal actions create-device component-props { name SERIAL value 9I0AZUN0V9J } component-props { name ID value 9I0AZUN0V9J }




Strangely kicker doesn't show action name "create-device" but reactive-re-deploy. Maybe this is normal.

kickers data-kicker "pre-condition: /pnp-service:pnp/map-plan{9I0AZUN0V9J}/plan/component{ns-pnp:managed-device 9I0AZUN0V9J}/state{ns-pnp:device-created}/pre-conditions/create/pre-condition{0}"
 monitor      /pnp-service:pnp/pnp-service:state[serial=$SERIAL]
 trigger-expr device-added
 variable ID
  value '9I0AZUN0V9J'
 variable PLAN
  value /pnp/map-plan[id='9I0AZUN0V9J']/plan
 variable SERIAL
  value '9I0AZUN0V9J'
 variable SERVICE
  value /pnp/map[id='9I0AZUN0V9J']
 variable ZOMBIE
  value "/ncs:zombies/ncs:service[ncs:service-path=\"/pnp/map[id='9I0AZUN0V9J']\"]"
 kick-node    /pnp-service:pnp/pnp-service:map[pnp-service:id='9I0AZUN0V9J']
 action-name  reactive-re-deploy

I need help how to debug nano service, more precise how to debug if certain pre-condition monitor is triggered and why action-name isn't executed (why stuck in create-init post action status). There is nothing in the log files related to the class CreateDeviceAction. It is like nso is unable to execute /pnp-service:pnp/pnp-service:internal/pnp-service:actions create-device


1 Reply 1

Cisco Employee
Cisco Employee


Somehow the post-action call was executed but NSO was unable to realize it. if you try the command: "show side-effect-queue", you will be able to see which call is stuck.  Also, just for troubleshooting, check the HA status of your deployment, if you are not using HA, make sure it is disabled in the ncs.conf file.

My 2 Cents.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: