Backup Failures (Bulk Configuration Manager)

[jborwi]

Hello,

• I'm using Bulk Configuration Manager within Configuration and Orchestration Manager to backup our 4000/5000 series switches.
• 2 out of the 71 nightly backups are failing with the following error message...
  • Error: Unknow device response while performing backup: [% Contacting TFTP host., % Writing configuration file. Current physical ID is 1, % Writing configuration file. Current phyiscal ID is 2, % Intra-stack communication failure., Operation aborted.
• Telnet connectivity to the device, and device credentials have been tested.
• Has anyone seen this error before?
• Any help would be greatly appreciated. Thank you.

[sprigent]

Hi.
I have seen this error in stack where base where temporary (eg unit 2 instead of unit 1)
check if stack is ok , and try a direct transfert to TFTP server .

[jborwi]

Thanks for your reply. I will check and let you know.
Thank you.

[jborwi]

One out of the 2 failed backup devices has a "temporary" base unit. I'll give it a reboot and test the backup again.

------------------------------------------------------------------------------
UNIT# Switch Model Cascade Up Cascade Down
------------------------------------------------------------------------------
1 4548GT-PWR OK OK
2 (Temporary Base)4548GT-PWR OK OK
3 4548GT-PWR OK OK
4 4548GT-PWR OK OK

[sprigent]

That's probably the reason for that stack.I have noticed that in this case the ascii backup was ok but not the bin.And unfortunately to recover the base , a reboot of the entire stack is necessary.For the second stack, is the stack OK (fully redondant ?)

[dmertz]

I received this error multiple times as well while using the Configuration Backup and Restore Portlet within BCM.

I performed a backup on all of our ERS 4800 Edge Switch stacks (~400 switches). For some reason, there were seven switch stacks that produced the same error that jborwi noted in the beginning of the post.

• The SNMP credentials are correct
• Telnet is functioning normally

What I ended up doing is creating a new task for those individual stacks, and after a few tries it finally worked.

That's probably the reason for that stack.I have noticed that in this case the ascii backup was ok but not the bin.And unfortunately to recover the base , a reboot of the entire stack is necessary.For the second stack, is the stack OK (fully redondant ?)

For reference, I went back and checked the health of each stack to make sure that there were no temporary bases assigned. I found that all of the stacks were fine.

So I think it's possible that stack health could be causing issues in some cases, but there could be other reasons at play. I have no idea what those reasons are, but I just wanted to share my experience.

Maybe someone else might have some more insight.