Skip to end of metadata
Go to start of metadata


Description:

Config Sync is used to synchronize the configurations between two VPN gateways or two WLAN controllers: When both devices have identical configurations, the slave can fully take over the functions if the master fails. If the synchronization stops working and changes are made to the master configuration, they will not be transferred to the slave. A failure of the master could cause communications to be restricted.

This article describes the steps to take if the Config Sync stops working.

To set up configuration synchronization between two WLAN controllers, select one of the two WLAN controllers in LANconfig and drag & drop it onto the other device. 

How to manually setup the configuration synchronization between two VPN gateways is described in this article.


Requirements:


Procedure:

1) Use the same firmware on both devices:

In principle, the Config Sync will work on devices with different firmware versions. However, if a firmware version implements a new feature and the addition of a new column to the command-line path, a conflict may arise since the entry is no longer unambiguous (see point 4).

For this reason we recommend that you use the same firmware version on both devices.



2) Check the Config Sync certificate:

Using SSH, connect to both devices and enter the CLI command show scep configsync cert to view the Config Sync certificate.

Check the following parameters:

  • Validity: The validity of the certificate must match on both devices. Small deviations like the one in this example are normal. This has no negative effects.
  • Subject: The IP address of the respective device must be included in the Subject
  • X509v3 Authority Key Identifier: This ID must be identical on both

  


2.1) Non-matching certificates on the two WLAN controllers:

Reset the slave to its factory settings and, in LANconfig, drag it onto the master again. This sets up the Config Sync anew and the certificate is obtained once again.


2.2) Non-matching certificates on the two VPN gateways:

Reset the slave to its factory settings and reconfigure it as described in this knowledge base article starting from step 2.



3) Check for error messages in Config Sync:

Connect to the master via SSH and enter the command ls /Status/Config/Sync/New-Cluster.

In this example an error has occurred:

  • Info: The incorrect parameter is displayed here.
  • State:  This shows the current status of the Config Sync. In this example, an error has occurred and the status is therefore invalid.


Possible statuses and troubleshooting:

  • Invalid: The error parameter under Info must be adjusted or deleted.
  • Changed: Settings were changed on the synchronization nodes (such as the IP address). On the device with the current configuration (master), execute the command do/Status/Config/Sync/New-Cluster launch or use the context menu in LANconfig to select the option Activate Configuration Synchronization Settings to restart the Config Sync.
  • Not-running: Config Sync has never been started. On the device with the current configuration (master), execute the command do/Status/Config/Sync/New-Cluster/Launch or use the context menu in LANconfig to select the option Activate Configuration Synchronization Settings to start the Config Sync.



4) LCOS as of version 10.40 on a VPN gateway: Adjustment of the "Ignored rows" table required

On a VPN gateway, the default route is usually excluded from synchronization by using the menu Management → Synchronization → Ignored rows.

After a firmware update to version 10.40 or higher the following error message is output (also see point 3):

In this case the row index needs to be supplemented with a 0 because the administrative distance was added as a new feature with firmware 10.40. The entry must therefore be 255.255.255.255 0.0.0.0 0 0.

The firmware update must be carried out on both devices, otherwise only one of the two devices will support the administrative distance feature, which would lead to a conflict.



5) When using the table "Access stations" the IP address of the other cluster member has to be stored as well:  

When using the table "Access stations" in the menu Management → Admin → Access settings → Configuration access ways the IP address (e.g. IP address 192.168.1.1 Netmask 255.255.255.255) or the whole network of the other WLAN Controller (e.g. IP address 192.168.1.0 Netmask 255.255.255.0) has to be entered in the table in order for the devices to be able to communicate with each other!