I´m new on Big IP and started my studies on LTM. I´ve set up two VEs running 22.214.171.124 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.
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
Its saying that there is no peer device configured. Can you establish the trust between both and try to sync again?
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 126.96.36.199 which is not working either. It´s very strange as 188.8.131.52 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!
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 184.108.40.206.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.
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 220.127.116.11 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: 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.
I have also run into this caveat. I am running 18.104.22.168 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.
issue still exists in version BIG-IP 22.214.171.124.
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.
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).