Unknown Sync State

Dazzla

 

 

What redundancy you using? Serial cable or network failover? Looks like the Active doesn't know if the Standby is up or not. Something to check. If the latter perhaps run a tcpdump to see if the failover traffic is working. On my version I used this tcpdump -ni 1.1 tcp port 1028.

 

 

Configsync traffic uses port 443 so perhaps can you try and telnet from the active to the standby on this port? Or again do a tcpdump on this port to see what's going on.

 

 

Hope this is some help.

 

 

N

Network failover. The device which should be active is reporting itself as active and the standby is reporting itself as standby. I can telnet from the active to the standby on port 443.

 

 

Thanks

I know tcp:1028 is used for connection/persistence mirroring and after doing a packet capture, it appears that's also the case for querying config sync status.

 

 

http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7225.html

 

 

From the active unit, can you telnet to 1028 on the standby's ip you're using for sync?

No can't telnet to port 1028 the connection is refused.

Is it port lockdown settings? Set to 'Allow default' on the relevant SelfIPs and test again.

Posted By Cspillane on 01/07/2011 02:22 AM

 

Is it port lockdown settings? Set to 'Allow default' on the relevant SelfIPs and test again.

 

This or a firewall. Since I'd assume it's the same VLAN, I'd expect it to be port lockdown as well.

The port lockdown is set to allow all. Yes the interfaces are on the same vlan and no firewall is between them. One thing I have noticed is the device certificate has expired.

What version of LTM are you using? Can you see any traffic at all from the Active to the Stanby over the configsync ip address?

 

 

N

Found a decent doc that shows troubleshooting steps. It does indeed say to telnet to 443 so Nathan was onto something there üòõ

http://support.f5.com/kb/en-us/solutions/public/7000/000/sol7024.html?sr=11998049

Item to checkSystemCommand or ProcedureDescription
Basic configurationPeer and SourceRun setup from the Configuration utilityRun setup prior to running ConfigSync.
ConnectivityPeer and Sourceping peerThe failover systems should be able to route to one another over a configured VLAN.

Verify that you can ping the IP address of the peer used by ConfigSync. An entry for the peer should exist in the /etc/hosts file. Alternatively, you can ping the peer IP address. Refer to the Database Entries below to determine the peer IP address entry.
Transport LTMPeer and Source


 telnet peer 443




You should be able to open a TCP connection to the peer system on the ConfigSync port.

Check Port Lockdown settings for the failover Self IP address and verify TCP 443 is enabled. For information, refer to SOL7317: Overview of port lockdown behavior. 
Transport ASMPeer and Sourcetelnet peer 3306
telnet peer 443If the BIG-IP system is licensed for the BIG-IP ASM module, the Self IP address should have TCP 443 and mysql enabled.

Check Port Lockdown settings for the failover Self IP address and verify TCP mysql and 443 are enabled. For information, refer to SOL7317: Overview of port lockdown behavior. 
FilesSource






Peerls -l /shared/tmp/__sync_local__.ucs






ls -l /var/local/ucs/__sync_remote__.ucsThe UCS collection file is created in the /shared/tmp directory on the local system.
The UCS collection file is installed to /var/local/ucs on the remote system.

Check the timestamps on the files. 

Verify that the expected files have been transmitted and installed. 

Check the UCS file sizes. If the UCS file is large in size, the ConfigSync operation may appear to hang or time out before the UCS file can be transferred to the peer system.
DirectoriesPeer and Sourcefind /config -xdev -type f | xargs du | sort -rn

and

find /home -xdev -type f | xargs du | sort -rnThe ConfigSync process may fail due to large disk usage under the /home or /config directories. For example, if the /home or /config directories contain a large ISO image or upgrade file, the ConfigSync process may timeout before completion. For more information, refer to SOL8522: The ConfigSync process may fail due to large disk usage under the /home or /config directories.
DaemonsPeer and Sourcebigstart status 
and 
bigstart status httpdBoth systems have the following daemons running for ConfigSync to complete.

Verify the following daemons are running on both systems:

mcpd 
cssd 
httpd 
bigdbd
Web AccountPeer and Sourceb db Configsync.Username show
and
b db Configsync.password showThe ConfigSync user web account and password is used for ConfigSync authentication, and should be the same on both units.

Check the Configuration utility and verify the proper web account is specified.

Check the Configsync.Username database entries

Looks like the csTest tool might be useful as well.

Running the csTest script

To run the csTest script, perform the following procedure:
Log in to the command line.
Type the following command to run the csTest tool:

csTest.pl --v
Running csTest in verbose mode will output the following ConfigSync debug information:
Status of daemons that should be running for ConfigSync to be operational
Configuration information used by ConfigSync, such as failover addresses, TCP ports, and ConfigSync accounts
Auto detect status
Network connection status
SOAP time difference check
Product version test and whether major and minor product versions are identical

Here's my output from csTest.pl --v, I'd recommend running it.

[admin@redactedName:Active] ~  csTest.pl --v
Status of daemons:
Warning: BigDB daemon (bigdbd) is not running.
Configsync configuration:
    Failover address (Self): redactedIP
    Peer IP address: redactedIP
    Configsync port: 443
    Configsync username: admin
    Acceptable time difference: 600 seconds
Configsync auto detect status:
    0 - Synchronized
    Last change (Self): 01/06/2011 12:47:50 (1294339670)
    Peer state is: known
    Last change (Peer): 01/06/2011 13:49:15 (1294343355)
    Last configsync: 01/06/2011 13:49:15 (1294343355)
    Peer update interval: 30 (seconds)
Network connection status:
    Local system is listening on configsync port (443).
    Ping test to peer redactedIP succeeded.
    SOAP connection test to peer redactedIP succeeded.
SOAP time difference check:
    Within the acceptable range.
Product version test:
    Major and minor product versions are identical. The maintenance
    versions are different.

The configsync tests completed successfully. You can run this
diagnostic tool on the peer redactedIP for further information.

443 is used for sync, maybe 1028 is just used to poll for changes?