UC560 backup to CCA failing with IOS error

[fenton]

Prior to doing a full upgrade of my UC560, I attempted to use CCA to do a backup of my configuration, voicemail, etc.  The process seems to get fairly far (backing up CUE), and then CCA informs me that the backup failed.

I was getting "%SYS-2-BADSHARE: Bad refcount in retparticle" errors, so I separately upgraded IOS on my UC560 (thinking this was perhaps an IOS error that had been corrected), but I'm still getting the errors.  Here's a sample of the errors I'm getting with uc500-advipservicesk9-mz.151-4.M4b :

000416: Dec 16 13:23:01.928: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A3240, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 82252944z 82252924z 8224C51Cz 816A5CD8z 802EAF48z 802F2494z

000417: Dec 16 13:23:02.228: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A3140, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 80027054z

000418: Dec 16 13:23:02.840: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A3C00, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 802EB0D0z 802EAFB4z 802F2494z

000419: Dec 16 13:23:04.040: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A2C80, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 80027054z 82FF68E4z 82FF68E4z 82252074z 8225266Cz 8224FD74z 8225DE94z 8224CA88z

000420: Dec 16 13:23:06.440: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A4A80, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 8030580Cz 802EA6DCz 802F2494z

000421: Dec 16 13:23:11.249: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A3900, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 81E7F228z 81E7F194z 81E9AD04z 81E7FB44z 81E7FCA0z 81E7FEECz 81E80124z 80303F40z

000422: Dec 16 13:23:20.973: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A4800, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 822525F4z

000423: Dec 16 13:23:21.277: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A3000, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 82249424z

000424: Dec 16 13:23:21.885: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A4680, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 816A5CCCz

000425: Dec 16 13:23:23.105: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A4A00, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 82FFCF44z 82FFCF5Cz 8343E318z 834474C4z 8343DB0Cz 8343F43Cz 82C42D98z 82C3CC94z

000426: Dec 16 13:23:25.505: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A2F00, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 80027054z

000427: Dec 16 13:23:30.309: %SYS-2-BADSHARE: Bad refcount in retparticle, ptr=877A4F00, count=0

-Traceback= 8177D0E8z 80384408z 80067460z 8006A8C8z 80305398z 800276DCz 800276DCz 80305458z 80027054z 82FF68E4z 82FF68E4z 82252074z 8225266Cz 8224FD74z 8225DE94z 8224CA88z

I'm reluctant to go ahead with the rest of the upgrade without having a reliable backup.

-Jim

[danplacek]

As you said -- upgrading would be a bad idea.

The first thing the update process in CCA does is create a backup -- if this fails, either the upgrade will hard fail then, or if it continues, your config/data will not be imported sucessfully after the upgrade.

There are some references to that error on google -- though for a different platform.

The fix mentioned is a reboot of the router... that would probably be a good place for you to start.

-Dan

[Alexander Maroukian]

Hi Jim,

Do you have "ip virtual-reassembly in" under all your ip interfaces - Gig0/0, Vlan1 etc.?

If not please add it and provide feedback.

HTH,

Alex

*Please rate helpful posts.

[fenton]

Alex,

Yes, the config already has "ip virtual-reassembly in" for Gig0/0, Integrated-Service-Engine 0/0, vlan1, vlan90, vlan 100. Any other ideas?

-Jim

[johschaf]

Hello Jim,

I would start by reviewing the connection requirements document:

https://supportforums.cisco.com/docs/DOC-9779

This docs discusses basic network configuration that will be needed in order to take a backup of the UC.

Thanks,

-john

[fenton]

Well, okay, I can (and will) review the connection requirements.  But are you saying that if I don't meet one of the connection requirements, an IOS internal memory management error will result? There shouldn't be anything I can do from a PC running CCA that results in a %SYS-2-BADSHARE error.

[johschaf]

Hello Jim,

No, I'd just like to start out by verifying the basic connection requirements. The error code you are seeing general refers to issues with the packets getting fragmented. Are you taking the backup locally?

Thanks,

-john

[fenton]

Yes, the PC running CCA is locally connected through a wireless connection to a Cisco Aironet 1142 access point (bridging) and SF300-48P switch. It's on the same subnet as the data subnet the UC560 is connected to.

[Dennis Bigelow · Accepted solution]

Jim,

You may also want to check your default gateway. If you are not using the UC as your default-gateway then make sure that the gateway has routes to all VLAN's of the UC. I have seen this a number of times where the default-gateway usually a firewall does not have the routes. Even though you can ping from your pc or do a route add it will still fail. The easiest method is connecting direct and changing your gateway to the UC.

Thanks,

Chris (Dennis)

[fenton]

Good call!  I neglected to consider the fact that our SA520 is doing the inter-VLAN routing, so it was routing packets to/from the CUE (VLAN 90).  I reconfigured my CCA PC to a static configuration with the UC560 as the default, and the backup succeeded with no %SYS-2-BADSHARE errors.

Good workaround, but hopefully there is a CDETS bug open for the error -- it should work with packet fragmentation as well.

Thanks!

-Jim