10-May-2018 08:04
Hi folks,
I´m new on Big IP and started my studies on LTM. I´ve set up two VEs running 13.1.0.5 software and I´m facing some issues in regards of synchronization of the configuration. I tried to create device-groups manually, rebuild the trust domain, push the last config from both devices, force an specific device to be the leader sync, restart processes (mcpd, devmgmtd, ntpd). Configsync-ips are correct and responding, mcpd connection in Established, I´ve already load conf to default (both VEs), read a lot of forums/discussion and at this time I´m still have no idea about why the status is Always “Not all Devices Synced. Most likely I´m missing something, did something wrong (or both).
Thanks in advance for the help.
Solved! Go to Solution.
09-Apr-2019 00:28
I have also run into this caveat. I am running 13.1.1.4 on VMware Workstation 15 on Fedora 29 Linux kernel 5.0.4
Thanks to the help of F5 FSE, I have managed to resolve it by adding the following DB variables on each VM on WMware Workstation 15.x:
tmsh modify /sys db tm.tcplargereceiveoffload value disable
tmsh modify /sys db tm.tcpsegmentationoffload value disable
It appears that WMware loses packets when offload is enabled.
10-May-2018 17:02
make sure time is sync in both devices
10-May-2018 17:51
Can you check your logs? Post any errors you see here to diag this issue? Did you configure a sync vlan....can you telnet to each other device on ports 443,22? Are both devices part of device trust? run the below commands
grep -i cmi /var/log/ltm
grep -i configsync /var/log/ltm
12-May-2018 10:20
Thanks for your reply, snl! I´ve set up a NTP server on both devices and also I tried to set up date and time manually however, it didn´t work.
Regards!
14-May-2018 08:13
Its saying that there is no peer device configured. Can you establish the trust between both and try to sync again?
14-May-2018 13:38
I am using VM workstation as well...and I never see the kind of behavior you are describing. So I am just curious. Anyway good luck.
17-May-2018 09:11
I have the same issues. Have you had a solution for that? Thanks in advance.
17-May-2018 13:03
Hello DNTDS,
Not at all... I´ve removed all the configuration from the VMs, installed again, licensed again and it didn´t work as well. I also tried to use 13.1.0.6 which is not working either. It´s very strange as 13.1.0.5 was working before.
The status in VEs keep on changing from "changes pending" to "awaiting initial config" and so on, other day the traffic-group-1 was have no devices on it...
Not sure what is happening... that´s sad!
17-May-2018 19:08
Have you tried another older version? I tried version 13.0.0.0.0.1645 and it worked.
21-May-2018 07:35
Hi DNDTS,
Sorry for the late response. I was planning to try another version but I wasn´t sure sure in which version to pick up. I´ve installed 13.0.0.3.0.1679 which has worked fine. I´ve just spent some precious time looking for na issue that doesn´t even exist.
Thanks for the advice.
Best Regards
27-Jun-2018
14:21
- last edited on
02-Jun-2023
09:09
by
JimmyPackets
Looks like bug 658716 as reported in 13.1.X release notes (https://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-13...)
We are having similar problems with 13.1.0.5 in a production system. Support said this bug was actually introduced in 13.0, so we had to downgrade to 12.X, which was a huge PITA because the config files are not downstream-portable.
Jun 27 14:05:27 ext-lb02 warning mcpd[27298]: 01071aea:4: CMI heartbeat timer expired, status: 10.10.16.1
Followed by HA disconnecting and daemons restarting, etc.
This is happening on only one of two pairs of HA vCMP guests. We're leaving the other pair of guests and the hypervisor alone for now.
07-Aug-2018 22:04
Issue persist as of Version BIGIP-13.1.1-0.0.4
09-Apr-2019 00:28
I have also run into this caveat. I am running 13.1.1.4 on VMware Workstation 15 on Fedora 29 Linux kernel 5.0.4
Thanks to the help of F5 FSE, I have managed to resolve it by adding the following DB variables on each VM on WMware Workstation 15.x:
tmsh modify /sys db tm.tcplargereceiveoffload value disable
tmsh modify /sys db tm.tcpsegmentationoffload value disable
It appears that WMware loses packets when offload is enabled.
23-Apr-2020 09:36
Thank you so much Krysitan Baniak, i've tried to run 2 above commands on each VM, it worked.
27-Jul-2020 11:49
Thanks a lot, Krystian. I have had the same issue for my VMware 12.5 lab with BIG-IP 13.1.1.4 version. The above command fixed the sync issue.
07-May-2021 02:59
Thanks it worked
09-Jun-2021 07:11
Thank you so much!
25-Jun-2023 05:52
thanks a lot ,i am running in 15.1.5.1 Build 0.0.14 on VMware Workstation 16. after use the two cmd, the device status from [awaiting initial config] to [In Sync].
11-Oct-2018 11:18
issue still exists in version BIG-IP 14.0.0.2.
I haven't been able to successfully sync two VEs running in VMware Workstation since 13.0.
Last version this worked was 12.1.x.
I do loads of demos, trainings, workshops etc. using the vLab environment. It's a pity I can't show DSC on any current version.
29-Oct-2018 16:02
I can partially answer this question. I was able to successfully configure DSC for VE v13.0.0 but with LAB license. Each VE required 8 GB of RAM and 4 CPUs (ESXi environment). Not sure if this works for Trial or Evaluation licenses as far I didn't manage to configure DSC with 4 GB of RAM and 2 CPUs per VE using both of those license types (VMware Fusion environment).
11-Sep-2023 07:02
Thank you for the tip, it worked! As I already tried many other solutions, I was about to trash my whole configuration + VE trial licences, and rebuild my environment from 0. Thanks to your suggestions, my issue was solved with just these two commands. I am using VMware Workstation Pro 17 + BIG-IP VE 17.0.0 0.0.22 trial version.
More info on the bug: