Forum Discussion

GDC1-TRG-F5's avatar
GDC1-TRG-F5
Icon for Nimbostratus rankNimbostratus
Jun 23, 2024

HA Sync issue on Active-Active Cluster

One of the peer shows the error "Does not have the last synced configuration, and has changes pending"
 
We tried syncing manually and the same error persists. 
As verified, NTP is in sync and there is no separate VLAN for HA.

Jun 18 09:23:18 Peer A notice mcpd[7966]: 010718ed:5: DATASYNC: requested force sync by user: xxxxxxxx
Jun 18 09:23:18 Peer A notice mcpd[7966]: 01b00004:5: There is an unfinished full sync already being sent for device group /Common/DG on connection 0xeba71348, delaying new sync until current one finishes.

Jun 18 09:24:19 Peer B notice mcpd[9977]: 010718ed:5: DATASYNC: requested force sync by user: xxxxxxx
Jun 18 09:24:20 Peer B notice mcpd[9977]: 01b00004:5: There is an unfinished full sync already being sent for device group /Common/DG on connection 0xeb6ee088, delaying new sync until current one finishes.
err mcpd[9977]: 0107102b:3: Master Key decrypt failure - decrypt failure - final(not sure if this is related)
 

Please suggest.

  • Hi , 
    First >>> It's recommended to configure a separate VLAN for HA with considering an aggregate link between both of devices specially in Active-Active scenario , as any failures could make a device to handle more traffic than it afford. 

    For your issue, please check the MTU in in your HA VLANS it could make such these issues. 
    Please have a look in this article: https://my.f5.com/manage/s/article/K13946

    to troubleshoot in MTU issues , you can use Packet capture on HA VLAN or a traceroute utility in BIGIP Linux shell , you can see if there is an error in fragmentation in the HA VLAN path between both of BIGIPs. 

     

  • Hello there! 

    This log caught my attention:

    err mcpd[9977]: 0107102b:3: Master Key decrypt failure - decrypt failure - final(not sure if this is related)

     

    in a BIG-IP HA cluster, peers usually sync their master key when you create the device group for the first time. 

    You can run the following command on both peers and see if they match: 

    f5mku -K

     

    If they don't, which would be wierd, you should probably fix this before you attempt to perform a config sync again. 

    f5mku -r <key> (I'd take the one from current active unit) 

     

    Other than that, you might try and restart TMM

    bigstart restart tmm

  • We verified the masterkey from both active and standby, found to be matching