I've got a pair of PIX 525 in an active/standby configuration. I recently made some fairly large configuration changes to the active pix. Ever since then, I'm getting some errors when writing the config to the standby unit. The error looks something like:
"At <date/time>, this active PIX was sending it configuration to the standby PIX and would not properly accept
configuration changes. After this PIX notifies ASDM that configuration synchronization is complete, ASDM will
send the current configuration changes.
Send configuration to the PIX now anyway rather than waiting?"
If I answer Send, I get another dialog which contains "write standby" and "Config replication in progress... Please try later."
How can I best get the standby pix back in sync with the active one?
I would suggest to double-check active/standby configuration first, go over this link, check physical connectivity between the two firewalls LAN base link.
Issue " show standby " on primary and take notes of standby output status information .. if your config appears correct this link will still provide you with information on how to sync up the two, there is also some debugs commands at end of link for failover issues.
I think the configuration is OK. This pair of PIXes has been in production use for some time now. The failover is cable-based. There seems to have been a failover to the secondary unit, and the primary unit is in a state called "sync config". The "show standby" wasn't available, but I could do a "show failover", are they equivalent?
Is there somewhere I can see the config for the secondary unit using cable-based failover? I've noticed that I can't connect to any of the secondary's addresses. Is that normal when it's failed over?
Sorry meant "show failover" not standby ..
you need to investigate why there was a failover, do you have access to the PIXes , try local console connection to the Primary the one in question, double check cable-base physical connection as well, there must have been a reason for the failover to occur.
as with any changes, backup all configs when performing troubleshooting .
you will need to issue failover active
from the console of the Primary in question, see instructions on link provided at very end of link " forcing failover " tests.
once you issue the command the unit should pool config from standby and take active role.
I agree it would be a good idea to find out why the units actually failed over, as it sounds like you have some connectivity issues since you can't access any of the Standby unit's interfaces (which you should be able to regardless of the failover state). Did the unit crash or reload due to a power failure. Check the output of 'show ver' (for uptime), 'show crash', 'show failover history', and any syslogs you have from the time of the problem to try to piece together why the failover occured.
In addition, configuring 'debug fover sync' will show you the configuration sync process. If the Standby unit is constantly getting stuck in a "config sync" state, you can monitor this output to see which commands are causing the sync to get stuck.
Hope that helps.
It looks like the problem started when I made a lot of config changes at once. I needed to move the outside interface from a built-in Ethernet interface to a gigabit Ethernet interface. I renamed the existing outside interface to old.outside, then renamed the GigabitEthernet1 interface to be outside. Then, I removed the config lines that still pointed to 'old.outside' and re-added them with 'outside' instead.
This is the first time I've made extensive changes to a pair of PIX configured like this. I didn't know how to check the replication until I started getting errors.
Is there any way to get the standby to dump whatever it has, get a complete copy of the config, and have the primary be the active PIX again? Will 'failover reload-standby' help with the first part of that?
thanks for posting the update, as we have indicated make sure Cable base failover is properly connected and that physical failover issues is ruled out. You will have to treat the failover implementation as in fact there was a fail firewall, if can you connect to the failed unit via console force the unit to become the active unit, the explanation to this is at the end of the Active/Standby link I provided..
I thought I had replied to this yesterday, but I don't seem to see it. Sorry if this is a duplicate...
So, I need to console into the primary unit and force it to be active? How can I be sure the config on it is the most up-to-date?
Thanks for all your help!
Just noticed on the primary... all the interfaces are down/up and the ip addresses are the same as the secondary... is that normal for the mode it's in?
I don't know if anyone is still following this thread, but I just had a thought. It's possible I started making config changes to the standby at first by mistake.
If that's the case, those changes you made will not be saved or replicated. So, to get the Standby unit back in sync you can simply toggle failover ('no failover', then 'failover') or reload and the configurations will sync back up. Any changes you made on the Standby would not have been replicated on the Active unit so that unit should be correct and up-to-date.
Ok, thanks, I'll try that. I notice that the primary unit (the current standby) has a startup config which shows some of the recent changes made to the config. When it gets reloaded, it will get the current config from the active unit, won't it?
Thanks for everyone's help... I had one more question on this. The primary (the current standby) unit shows the same set of ip addresses in 'show ip' under 'System IP addresses' as 'Current IP addresses'. The 'show failover' command shows the expected results (under 'this host' all interfaces show the standby's ip addresses. It's almost as if it failed over to the secondary, but the primary kept the same addresses and its interfaces got shut down due to ip conflict.
I'm going to reload the primary and if it comes back up as the standby unit, I'll do a 'failover active' to make it active again.