Applying configuration template to ePMP - Job gets stuck but configuration applies

Hey all, I'm having a strange issue with on-prem version 1.6.3-r39 (Upgrading soon).  I am attempting to update the configuration of some ePMP devices with a template in cnMaestro, but every device just hangs at "Initiated configuration update operation." before eventually moving to "Device times out while waiting for update" in the job queue whenever I run it.  However, when I check the SMs their config has changed like it was supposed to.  My guess is that for some reason, the SMs aren't reporting back to cnMaestro once the config has been updated?  The template must work, as the changes got applied, but here it is anyways:

{
"device_props": {
"networkLanDNSIPAddrPrimary": "1.1.1.1",
"networkLanDNSIPAddrSecondary": "1.0.0.1"
}
}

Any advice?

Hi Nekomata,

I have forwarded this post to some collegues to confirm this behavior.  Did the SMs disconnect from cnMaestro and/or reboot when you applied this change?  What firmware version(s) are they running?

1 Like

Hi Nekomata,

We've reproduced this locally and have opened a ticket to fix this issue.  Thank you for bringing this to our attention.

1 Like

I'm glad to hear you guys found the issue, I was beginning to wonder if it was just on my end.  In response to your other question (if it still helps at all), the SMs are on 3.5.2 firmware, and they did experience a session drop after attempting to apply the template.

1 Like

What version of cnmaestro was this fixed?  we are having this problem with PMP450s going to initiated state, the config does get applied, but we have to abort the job in order to move on to the next job.  the configs are good to go in the SM's and AP's that do this.

It looks like this was marked as fixed in ePMP version 4.4. 

This occuring in PMP450 would be a separate issue though.  Can you share the device firmware version and the template you are applying either in a PM or this thread?

Hi I have the same issue with the ePMP, is there any way to fix it without upgrading to firmware 4.4?.

No, the cause had to due with device behavior itself, so an upgrade to 4.4.0 is required to get the fix.

This has to due with some template changes requiring a certain sub-system on the device to needing to restart.  So depending on what changes are being applied, some might not see this issue.

Since you do see it with your template, an upgrade to 4.4.0 is required.

If upgrading is not an option, the configuration jobs will run slower while waiting for devices to timeout.  You can increase the parallel update limit to the max when create a configuration job to make this less time consuming.

If configuration alarms are activated as a result, you can get them cleared by pushing an empty or trivial template update to impacted devices that doesn't actual change what is running on the device.  This will result in a successful configuration update and will automatically clear open Configuration alarms.