PIX 515E Failover doesn't recover

[richmorrow624]

I have two PIX 515E firewalls v7.01 configured in a failover scenario.

Both units were working with no problem. Primary was working fine and configuration changes were transferred to secondary.

Per TAC support, the only thing needed to test the failover was to issue a "reload" command on the primary and have the secondary take over as the primary. Then, issue "failover active" on the reloaded unit once it was back up in the secondary role.

The failover to the secondary unit worked with no problem, it was a seamless transition to the secondary unit.

The problem came in that the original primary unit is stuck in a loop when trying to reload with what looks like configuration errors now. It will not successfully boot up.

Is this not a valid procedure to test the failover?

It seems that in the real world, this could actually happen the failover should work?

Some of what is shown:

Config ERROR: invalid log level/keyword <inactive> specified; level must be emergencies (0) - debugging (7)

Config Error -- access-list acl_in extended permit tcp any host 208.13.32.36 eq smtp log

*** Output from config line 359, "access-list acl_in exten..."

Config Sync Error: Following command could not be executed on standby

Platform

access-list acl_in permit tcp any host 208.13.32.36 eq smtp log inactiv

Use BREAK or ESC to interrupt flash boot.ridge/vlan/modify): m

e inactivea VLAN

******REPLICATION OF CONFIGURATION FROM ACTIVE TO STANDBY UNIT IS INCOMPLETE,

Reading 115200 bytes of image from flash.

TO PREVENT THE STANDBY UNIT TAKING OVER AS ACTIVE WITH A PARTIAL CONFIGURATION,THE STANDBY UNIT WILL NOW REBOOT*******

[jgervia_2 · Accepted solution]

You're not going to like this answer.

It appears that commands typed in and abbreviated by cisco in the configuration aren't valid when copied/pasted in or when the firewall is reloaded or receives the config from an active firewall.

I don't know exactly what you did, but here's what I did to reproduce your issue:

I typed in the command:

access-list acl_in permit tcp any host 208.13.32.36 eq smtp log informational interval 300 inactive

Since 'log informational interval 300' is the default, this actually gets saved in the running-config as:

access-list acl_in permit tcp any host 208.13.32.36 eq smtp log inactiv

This is *not* a valid command (the word following 'log' needs to be a log level), if you try to type it in. When you rebooted the firewall, it tried to pull the config from the active device (since it's now standby), received this line, and since it can't execute it (because it's not a valid command), it keeps rebooting itself so it can't take over and be the active firewall.

Easiest way to do it is to take that line (and any other lines like it) out of the now active firewall - as that line is marked 'inactive' anyway, this shouldn't affect you. The other way would be to change that line to something non-default (change the logging level may be easiest). That way when the primary/standby reboots itself again, the command it receives will have a valid log level (or if you took the lines out, they won't be an issue) and will allow the rest of the configuration to be processed.

You might also want to report this to cisco as a bug, if they aren't combing these forums already.

--Jason

Rate this if it helps.

[richmorrow624]

Jason,

Thanks for the reply...

You are exactly right in your reply. I actually found this earlier this evening after posting.

There were actually two lines that were no longer applied, but had not been deleted and were copied to the standby firewall during normal failover operation.

After the failover had been initiated, everything worked fine.

But, just as you said, it would bomb out when it tried to copy those line back to the primary during reboot.

What I did to fix it is this:

Since it was inactive anyway, I just put the line back in the active firewall without the logging level at all, then deleted them.

Luckily, it let me do it. I was afraid it might not let me overwrite the lines, but it did.

Both firewalls are back on line now, I appreciate your effort in helping me resolve this.

Richard