Config Sync problem

Hi Chris,

 

 

It could be a disk space issue (most common if you're running on the compact flash slot):

 

 

SOL8522: The configsync process may fail due to large disk usage under the /home or /config directories

 

https://support.f5.com/kb/en-us/solutions/public/8000/500/sol8522.html

 

 

You can get details and troubleshooting steps for the config sync process in SOL7024:

 

 

SOL7024: Overview of the configsync process

 

https://support.f5.com/kb/en-us/solutions/public/7000/000/sol7024.html

 

 

Aaron

Thanks for the quick response Aaron.

 

after running csTest.pl -v I got the following results:

 

It seems like "3 - Config modified on both systems, manual intervention required" might be the "source of all evil"

 

Any help most welcome

 

 

[root@big-ip1:Active] config csTest.pl -v

 

Status of daemons:

 

All required daemons are up and running (MCPD, CSSD, HTTPD, and BigDBD).

 

Configsync configuration:

 

Failover address (Self): xxxxxx

 

Peer IP address: xxxxxx

 

Configsync port: 443

 

Configsync username: admin

 

Acceptable time difference: 600 seconds

 

Configsync auto detect status:

 

3 - Config modified on both systems, manual intervention required

 

Last change (Self): 10/14/2008 16:48:29 (1223995709)

 

Peer state is: known

 

Last change (Peer): 10/14/2008 17:08:42 (1223996922)

 

Last configsync: 03/18/2008 14:30:37 (1205847037)

 

Peer update interval: 30 (seconds)

 

Network connection status:

 

Local system is listening on configsync port (443).

 

Ping test to peer xxxxxx succeeded.

 

SOAP connection test to peer xxxxxx succeeded.

 

SOAP time difference check:

 

Within the acceptable range.

 

Product version test:

 

Major and minor product versions are identical. The maintenance

 

versions are different.

 

 

 

Do you have a hotfix installed on one unit which isn't installed on the other unit? I didn't think this would cause a config sync error, but that's the only message which looks interesting to me. If you do have different hotfix levels on the two units, can you install the hotfix on the second unit and retest the config sync process?

 

 

Another test option: if you manually copy a UCS from the source unit to the destination and use 'b config install /path/to/source.ucs' does it work?

 

 

Aaron

Yes, the "3 - Config modified on both systems, manual intervention required" is no big deal, it just means both units have a newer timestamp on their respective configs than the last successful configsync time and the user must decide which one has the correct config.

 

 

Hotfix level differences can definitely cause units not to sync, either from changes in config syntax or from changes in the configsync code itself.

 

 

Denny

Nice tips guys.

 

Its seems like I'm running BIG-IP Version 9.4.3 14.3 Hotfix HF3 Edition on the active node

 

and BIG-IP Version 9.4.3 11.0 Hotfix HF2 Edition on the passive node.

 

I am thinking about doing the following (node 1 is the active node at the moment and node 2 the passive node):

 

Install HF4 on the passive node (2)

 

Force a failover to make Node 2 with HF4 active.

 

Make sure that everything works.

 

Install HF4 on Node1

 

Run config sync

 

Force a failover to check that this works.

 

Go home!

 

Or maybe I should pickup a HF3 (if I can find it) for the passive node and try a config sync - this might be less risky.

 

Extra infos: Although after running config sync and getting this error message something seems to be crashing, the changes that I made to node 1 have been synced to node 2 - Strange.

 

 

Any thoughts welcome!!

 

 

Thanx again

 

 

Chris

 

If you're going to upgrade both units, I'd suggest installing 9.4.5 with hotfix2. If you check the 9.4.5 release notes and the HF2 readme, you'll see that there have been a lot of significant fixes in each. You can download the release and hotfix from downloads.f5.com.

 

 

Aaron

Thanks one again, Aaron,

 

Can I upgade both units a described in my last post or is there a better method.

 

Regards

 

 

Chris

 

Does unit2 look like it has a valid configuration? If it does, then yes, it would be good to upgrade unit2 while standby to 9.4.5, install HF2, fail over to it, check that traffic processes correctly and then upgrade unit1. You could install 9.4.5 on a second harddrive slot and leave 9.4.3 on the current active slot. This gives you two methods for backing out the upgrade in the event of a problem: failing over to the peer unit on the original version or using switchboot to boot back to the 9.4.3 slot on unit2.

 

 

You can get details on the switchboot command in SOL5658:

 

 

SOL5658: Overview of the switchboot utility (Click here)

 

 

If the configuration on unit2 is suspect, you should try to fix that before upgrading the configuration. If there are daemons restarting, errors in the /var/log log files, or it doesn't stay in standby mode with the peer, you could open a case with F5 Support and ask them to help you diagnose the issues before upgrading.

 

 

Aaron

Ok Aaron, so I guess I will try a failover with the present setup before continuing.

 

I guess a "no risk" deal would be to install 9.4.3 14.3 Hotfix HF3 on node 2 and then try config sync.

 

Do you have any idea where I can get this version?

 

Thanks again fór the time

 

 

Chris

Hi Chris,

 

 

Yes, installing 9.4.3 HF3 and doing a config sync first would be a safe bet. After confirming traffic works on that version, you could upgrade to 9.4.5HF2.

 

 

If 9.4.3HF3 isn't still on the peer unit (under /var/tmp/?) or downloads.f5.com, you can open a case with F5 Support and request it.

 

 

Aaron