Standby ACE-4710 lost its configuration after a reload !

yves.haemmerli · ‎10-21-2009

Hi,

I have two ACE-4710 in active/standby mode, running code A3(2.2). Four contexts are configured. Both devices were functional without problem, until I reload the standby unit. After reload, the standby unit completely lost its configuration with exception of the FT vlan and the FT peer configuration in the Admin context... Both units recognized each-other and I can still ping the primary unit on the FT vlan, but nothing else. Contexts are lost and interfaces are shutdown! Nothing changed at the software level, both devices run exactly the same image and the same licences are installed (it worked well before the reload).

So, I decided to reconfigure the basics on the standby unit in order to trigger a config sync from the primary. And here arrives the problem : I reconfigure the FT vlan, the FT peer, I check the peer state and everything is OK.

Then, I try to ping the primary unit from the standby unit with success :

switch/Admin# ping 192.168.16.1

Pinging 192.168.16.1 with timeout = 2, count = 5, size = 100 ....

Response from 192.168.16.1 : seq 1 time 0.000 ms

Response from 192.168.16.1 : seq 2 time 1.413 ms

Response from 192.168.16.1 : seq 3 time 0.000 ms

Response from 192.168.16.1 : seq 4 time 0.404 ms

Response from 192.168.16.1 : seq 5 time 0.386 ms

5 packet sent, 5 responses received, 0% packet loss

And now, I want to configure the FT group associated with the Admin context, in order to trigger the config sync. But, as soon I enter the statement "inservice", the following messages are displayed and the ft group is not created, as shown in the following screen shot :

switch/Admin(config)# ft group 11

switch/Admin(config-ft-group)# peer 1

switch/Admin(config-ft-group)# priority 150

switch/Admin(config-ft-group)# peer priority 200

switch/Admin(config-ft-group)# associate-context Admin

switch/Admin(config-ft-group)# inservice

NOTE: Configuration mode has been disabled on all sessions

switch/Admin(config-ft-group)#

NOTE: Configuration mode is enabled on all sessions

`no interface gigabitEthernet 1/4`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/3`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/2`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/1`

*** Context 0: cmd exec error ***

switch/Admin(config-ft-group)#

switch/Admin# sh run

Generating configuration....

boot system image:c4710ace-mz.A3_2_2.bin

interface gigabitEthernet 1/1

shutdown

interface gigabitEthernet 1/2

ft-port vlan 16

no shutdown

interface gigabitEthernet 1/3

shutdown

interface gigabitEthernet 1/4

shutdown

ft interface vlan 16

ip address 192.168.16.2 255.255.255.0

peer ip address 192.168.16.1 255.255.255.0

no shutdown

ft peer 1

heartbeat interval 300

heartbeat count 10

ft-interface vlan 16

username admin password 5 $1$UjGM.es0$1Np.PYfQlRxoGVDHngvmp. role Admin domain

default-domain

username www password 5 $1$M8kBDLSG$En11xoF7/GKQlUoB/hDpv/ role Admin domain de

fault-domain

As it is impossible to get the standby unit synchronized, I decided to write erase the config in order to start from scratch. But here too, the same errors occur when putting the ft group inservice.

Any idea what the problem could be ? I suspect a bug...

Thank you for any help

Yves Haemmerli

abarisone · ‎10-15-2012

Hi yves,

Today I' ve experienced the same problem. I ' ve searched a lot all around but anyone gave me any ideas.

I think it' s a problem in the configuration file. When I write "inservice" the configuration pass from active to standby (I've seen using sh startup config on the standby unit) and after few seconds I see the errors:

`no interface gigabitEthernet 1/4`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/3`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/2`

*** Context 0: cmd exec error ***

`no interface gigabitEthernet 1/1`

*** Context 0: cmd exec error ***

Also using a new brand ACE the problem persists. If you have any ideas or solution to share thank you in advance.

Anyway tomorrow I will test little blocks of configuration in order to find the errors...

Thank you

Ale

Giovanni Dambrosio Ocampo · ‎10-15-2012

Hi Guys:

This issue is cause by a software issue:

CSCtu34037

— User context configurations (including certificates and keys) are lost after the ACE reloads. When this issue occurs, the Admin context configuration is reduced to the minimal, initial configuration. This issue can occur when you specify the

reload

command, or if the FT link is interrupted by high CPU usage on the switch that the ACE is connected to. Workaround: None.

This will be fixed on the latest 4.x code (A4(2.3)).

Even when the bug says that it does not have a work arround you should contact TAC asking for a script that will prevent the config to be erased, however if you already did a write mem, then a manual back up would be needed.

Hope it helps,

Best regards

Giovanni DAmbrosio

Kanwaljeet Singh · ‎10-15-2012

Hi,

I did a search internally and i think you will need to open a TAC case. Can you collect show tech from ACTIVE ace and see if it gives any error?

You may be hitting this DDTS: CSCtx03563. This can cause the behavior you are facing above after reloading the ACE. You may need to upgrade or use workaround script provided by TAC.

Regards,

Kanwal