Hello there, First of all, great forum! The irules tips have helped me a great deal over the last months! got a slight problem with 2 Big-IP 6400's that do not want to sync. I would like to push my config from the active to the passive box. Now the passive 6400 has a newer config than the active one (not intentionally!) When performing a sync from the gui or from the cli, I get the following message: [root@big-ip1:Active] config bigpipe config sync all Saving active configuration... Configsync Mode: Push Transferring UCS to peer... Installing UCS on peer... SOAPException: 'Unexpected return Content-Type: text/html; charset=iso-8859-1' Transport and install failed Error running config sync all. BIGpipe parsing error: 01110001:3: Error running config sync all [root@big-ip1:Active] config Both boxes have the same hardware and used to sync just fine. Any sort of infos welcome. Maybe there is some king of debug mode that writes the error to a log file? Thanx Chris

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

Config Sync problem | DevCentral

19 Replies

ChrisMaKi_15830
Nimbostratus
Oct 15, 2008
Cheers Aaron.

Now I have enough information to get moving on this issue.

Here is a virtual beer for the help!

Chris
ChrisMaKi_15830
Nimbostratus
Oct 15, 2008
As soon as I have resolved this issue I will post the sollution for future reference.

Chris
hooleylist
Cirrostratus
Oct 15, 2008
Good luck... and thanks in advance.

Aaron
ChrisMaKi_15830
Nimbostratus
Oct 16, 2008
Hi all,

it's me again.

I've upgraded node 2 and guess what - it syncs.

I was suprised to discover that there were different versions of software on the nodes (I didn't install them - honest)!!!!

Thanks again for the help!

Chris
VB_95896
Nimbostratus
Nov 17, 2008
Hi,

I have got a little problem with 2 units "Big-IP ASM" (platform : "4100") running version "9.4.5" (+ Hotfix).

When performing a sync (in the GUI) from unit-2 (active) to unit-1 (passive), I get the following message :

---------------------------------

Operation Status

Configsync Mode: Push

Transferring UCS to peer...

Installing UCS on peer...

Obtaining results of remote configuration installation...

Saving active configuration...

Current configuration backed up to /var/local/ucs/cs_backup.ucs.

tar: SPEC-Manifest: time stamp 2008-11-17 10:06:46 is 18 s in the future

tar: SPEC-Files: time stamp 2008-11-17 10:06:48 is 20 s in the future

tar: SPEC-Manifest: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: SPEC-Files: time stamp 2008-11-17 10:06:48 is 19 s in the future

tar: var/tmp/ts_db.save_dir_location.cstmp: time stamp 2008-11-17 10:06:45 is 16 s in the future

tar: var/tmp/ts_db.save_dir_6675.cstmp/ts_db.data.PLC.SIGFILE_STATUS.cstmp: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/ts_db.save_dir_6675.cstmp/ts_db.schema.PLC.SIGFILE_STATUS.cstmp: time stamp 2008-11-17 10:06:46 is 17 s in the future

...

...

tar: var/tmp/ts_db.save_dir_6675.cstmp/ts_db.data.DCC.ACCOUNTS.cstmp: time stamp 2008-11-17 10:06:45 is 16 s in the future

tar: var/tmp/ts_db.save_dir_6675.cstmp/ts_db.schema.DCC.ACCOUNTS.cstmp: time stamp 2008-11-17 10:06:45 is 16 s in the future

tar: var/tmp/ts_db.save_dir_6675.cstmp: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: config/ucs_version: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: config: time stamp 2008-11-17 10:06:43 is 14 s in the future

tar: config/bigip_base.conf: time stamp 2008-11-17 10:06:43 is 14 s in the future

tar: config/BigDB.dat: time stamp 2008-11-17 10:06:35 is 6 s in the future

tar: config/bigip_sys.conf: time stamp 2008-11-17 10:06:43 is 14 s in the future

tar: config/bigip_local.conf: time stamp 2008-11-17 10:06:43 is 14 s in the future

tar: config/bigip.conf: time stamp 2008-11-17 10:06:43 is 14 s in the future

tar: var/tmp/cert_temp/conf: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/cert_temp/ssl/ssl.key: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/cert_temp/ssl: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/cert_temp: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/gtm_tmp/big3d: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/gtm_tmp: time stamp 2008-11-17 10:06:46 is 17 s in the future

tar: var/tmp/em_db_temp: time stamp 2008-11-17 10:06:46 is 17 s in the future

Hostname of UCS file is F5.info3.delta.int, local hostname is F5.info1.delta.int

Installing shared configuration on host F5.info1.delta.int

Installing...

Installing ASM configuration...

Reloading configuration... It may take a few minutes...

Reading configuration from /defaults/config_base.conf.

Reading configuration from /config/bigip_base.conf.

Reading configuration from /config/bigip_sys.conf.

Reading configuration from /usr/bin/monitors/builtins/base_monitors.conf.

Reading configuration from /config/profile_base.conf.

Reading configuration from /config/daemon.conf.

Reading configuration from /config/bigip.conf.

Reading configuration from /config/bigip_local.conf.

Loading the configuration ...

Loading ASM configuration...

Synchronizing Master Keys...

Saving active configuration...

---------------------------------

As you can see, the sync log shows several messages of the type "time stamp ... is X seconds in the future".

However, when performing a sync (in the GUI) from unit-1 (active) to unit-2 (passive), everything seems OK.

(nothing relating to a time stamp difference).

Any info is welcome,

Thanks,

VB
hwidjaja_37598
Altostratus
Nov 17, 2008
I believe there is a change with the system time. If you had recently made some changes to the NTP server, the unit probably had its time rolled back a little bit based on the settings it received from the time server.

It looks as if you had successfully synchronized these units and I wouldn't worry about the messages you saw.

Try to reboot the box and ConfigSync again.
venublr_96201
Nimbostratus
Oct 01, 2009
Accidentally one of the hostname (Standby box) changes same as active box. If we do a config sync from the active box does config sync fail ?
hooleylist
Cirrostratus
Oct 01, 2009
It would be a big issue if the config was sync'd to the peer if both units have the same hostname. If the units have different hostnames and a UCS is loaded (or the config is sync'd) only the shared config is loaded. If both units have the same hostnames, then the entire config (including the base network config) will be loaded. The result would be that both units would try to answer for all of the same self IP addresses and all load balancing would potentially fail.

I'd suggest correcting the hostname configuration error as soon as possible and not sync'ing the config until that is done. Make sure to take current UCS backups once you fix the hostname error.

Aaron
venublr_96201
Nimbostratus
Oct 01, 2009
Aron

Quite informative and appreciate your quick response.

Thanks

Venugopal

Forum Discussion

Config Sync problem

19 Replies

Recent Discussions

ASM instance creation

BIG-IP DNS: Check Status Of Multiple Monitors Against Pool Member

Open Redirection Mitigation

F5Access | MacOS Sonoma

enable tls1.2 on management interface on F5 ltm running version 10.x

Related Content

disable config sync upgrade GTM

Sync-failover group doesn't sync properly

Perl Config Sync

virtual server config

F5 Config Sync Issue