Applies To:

Show Versions Show Versions

sol9465: The ConfigSync auto detect indicator will incorrectly show that a ConfigSync is required or recommended
Known IssueKnown Issue

Original Publication Date: 12/01/2008
Updated Date: 05/27/2016

Known Issue

The BIG-IP system's ConfigSync auto detect indicator will incorrectly display a message of either Sync Recommended or Sync Required in the Configuration utility. This issue occurs when all of the following conditions are met:

  • The BIG IP system is configured as part of a high availability pair.
  • The Configsync.Autodetect variable is set to enable.
  • A user clicks the Update button anywhere in the Configuration utility.

When systems in a high availability pair have identical configurations, clicking the Update button anywhere in the Configuration utility will update the local configuration file timestamp. This timestamp change is detected as a configuration modification which triggers the ConfigSync auto detect feature, even though no other change has been made to the configuration.

BIG-IP high availability pairs exchange messages that indicate the date and time stamp for their current configuration files. The BIG-IP systems use the information in these messages to determine whether the ConfigSync process is needed. When the configuration on one of the members has changed, the ConfigSync auto detect indicator in the Configuration utility will change to inform the BIG-IP administrator that the devices are out of sync.


This issue will result in the ConfigSync auto detect feature falsely reporting that the configurations for the members of high availability pairs are out of sync. This may result in administrators unnecessarily syncing the configurations.


As a result of this issue, the BIG-IP system's ConfigSync auto detect indicator will show that a ConfigSync is required or recommended. When this occurs, the BIG-IP Configuration utility will report one of the following messages:

  • Sync Required
  • Sync Recommended

Additionally, the value of the db variable Configsync.State will be set to 1 or 2, as shown in the following two example results of the command bigpipe db Configsync.State:

Configsync.State = 2 - Peer config modified, recommend configsync from peer

Configsync.State = 1 - Local config modified, recommend configsync to peer


F5 Product Development has assigned ID 249309 (formerly CR118404) to this issue, and has confirmed that this issue exists in the products listed in the Applies To box. For information about releases or hotfixes that resolve this issue, refer to the following table:

Type of FixVersions FixedRelated Articles

* As a result of changes, this issue does not affect BIG-IP 11.x and later. For help with ConfigSync issues in BIG-IP 11.x, refer to SOL13946: Troubleshooting ConfigSync and device clustering (11.x).


You can avoid this issue by not clicking the Update button in the configuration utility unless a change has been made.

Note: Clicking the Update button in the BIG-IP Configuration utility does not refresh the information on the currently-viewed screen, it updates the configuration. For example, clicking the Update button on the ConfigSync screen after pushing a synchronization update from the peer will not clear the Sync Required or Sync Recommended message on the local system. Instead, clicking the Update button updates the configuration again, triggering yet another Sync Required or Sync Recommended message.

You can remove the synchronization recommendation message from the BIG-IP display by synchronizing the pair, or by setting the Configsync.LocalSyncedTime database key to the same value on both systems in the BIG-IP LTM high availability pair. To do so, perform the following procedure:

  1. Log in to the command line of the BIG-IP redundant system.
  2. Reset the Configsync.LocalSyncedTime database key on each device to the current date and time of the Unix time stamp, by typing the following command:

    bigpipe db Configsync.LocalSyncedTime `date +%s`

    Note: The date +%s command returns the current time, in seconds, since the UNIX epoch. For instructions about manually converting time into seconds, since the UNIX epoch, refer to SOL148: Converting a date and time into the number of seconds since the beginning of the UNIX epoch.

  3. Repeat this procedure on the other member of the redundant system.

Supplemental Information

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)