Traffic Group Properties

v11? Which one?

In v11, DSC (Device Service Clustering) changed a few times... Later versions (11.4.1+) are much better and have far fewer bugs in the device clustering and syncing... In 11.2.1 for example, it's perfectly possible to have a config that LOOKS synced, but the cluster itself isn't synced... Or a cluster that won't sync because it thinks a sync is in progress... Or several other combinations...

It's probably worthwhile using the cluster sync tools (I think there's a SOL note around here somewhere with the tools in it) to determine exactly what part of the cluster & traffic-group sync is failing. (there could be a hint in the ltm logs as well)

a shot in the dark (going off of hamish's post) It sounds as if your configs are synced but maybe not your device-trust-group. Depending on your code-level, run the tmsh command "run cm watch-devicegroup-device" or from bash "watch_devicegroup_device". This will show you the sync-status of the various sync/trust groups configured on the F5. The CID.id should be the same for the type of group if the group is in sync. If the device_trust_group shows different CID id's for the devices in the group, try making a benign change to the trust group in the configuration utility - navigate to device management | device groups | and enter a description. This should automatically sync once you click "update"

Sorry - the version is 11.4.1 HF4

watch_devicegroup_device shows device_trust_groups with the same CID

sync_failover_device_group the 2 nodes have different CIDs and CID.time

Thanks

JKrum

I will open a case and update this thread.

Thanks

People keep mentioning ConfigSync when ConfigSync is NOT the issue. Forgive the frustration, but I've beaten my head against this for two days. Yes, I have opened a ticket. I have the same exact issue. Both LTMs are synced, but on the Primary LTM the traffic group lists only the Active LTM--as "current device"

Underneath that is "Next Active DeviceInitializing / Not Synced"

Essentially, the active F5 does not see the standby as being in its traffic group, even though both appear in the HA order box, even though the standby does sees the active. The gui on each is exactly the same, save that on the standby, the correct ltm name appears as "Next Active Device"

Testing this on a virtual pair with no traffic, andI found that if I force the primary to standby, 1. The previous standby LTM will go Active 2. Then the originally active LTM goes active AGAIN 3. And the previous standby LTM falls back to standby.

So the standby LTM behaves as it should, but as far as the primary is concerned, it is the only active ltm in the traffic group. Auto-failback is NOT enabled on either LTM

Each LTM shows itself and its alleged partner under "device management | devices." Config sync does indeed work with no issues.

I just upgraded three pairs of virtual LTMs from 11.4.1 to 11.6.0 on our viprions, and each pair has the same exact problem. Also, each of the Active LTMS with the issue are hosted on the same chassis, so there may be an issue on the chassis itself forcing the behaviour, but I am damned if I can figure out what it would be.

Was the problem ever identified? I just saw this behavior with Viprion 2100 blades, 11.5.1 HF7. One of the units had failed during an attempted upgrade to 11.6.0, and when I brought up the RMA I found config sync worked fine but traffic groups were a complete mess. The new unit took over as active but was showing "Initializing / Not Synced". The standby reported the expected status, but if I modified the traffic groups, it would drop its network connections several times before finally stabilizing after a few minutes.

For us the following worked on version 11.6.0 HF4:

"bigstart restart sod"

Because you will restart this process, the load balancer will again check his traffic groups and status. We saw that the 'next device option' has been filled in with the other node after we restart the SOD process.

After this we were possible to put the active node in standby modes and otherwise.

Remember: After a reload/reboot of the node the same behavior can be coming back. So check this we you do a reload of a reboot.

This is known bug by F5 and haven't been solved in the version 11.6.0. HF4.

Regards,

Frans van Dokkumburg

The other option what it can be is that you forget to set the "enabled" option wihtin the sync-failover setting

Device Management >> Device Groups

Go to the Group what have as type "Sync-Failover" Go to the Tab "Failover"

check the "enabled" checkbox

Yeah, I've had this issue numerous times....mainly on vCMP...

with vCMP I can't remember what the best solution was, it was trial and error. I can remember resetting trusts etc..

However just had the same issues setting up some old 1600s without a serial failover cable. They do have a point to point failover ethernet connection which I had defined as the network failover. When I also defined the mgmt connections in the unicast address list it all magically started working...! This isn't an option on vCMP though....