Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Devices are not synchronizing configuration to each other

K1974_98730
Nimbostratus
Nimbostratus

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.

 

1 ACCEPTED SOLUTION

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.

 

View solution in original post

20 REPLIES 20

Snl
Cirrostratus
Cirrostratus

make sure time is sync in both devices

 

Domai
Altostratus
Altostratus

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

 

K1974_98730
Nimbostratus
Nimbostratus

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!

 

Domai
Altostratus
Altostratus

Its saying that there is no peer device configured. Can you establish the trust between both and try to sync again?

 

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-...

 

Domai
Altostratus
Altostratus

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.

 

DNDTS_361701
Nimbostratus
Nimbostratus

I have the same issues. Have you had a solution for that? Thanks in advance.

 

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!

 

Have you tried another older version? I tried version 13.0.0.0.0.1645 and it worked.

 

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

 

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.

Issue persist as of Version BIGIP-13.1.1-0.0.4

 

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.

 

Thank you so much Krysitan Baniak, i've tried to run 2 above commands on each VM, it worked.

 

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.

Thanks it worked

Thank you so much!

 

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].

gha
Nimbostratus
Nimbostratus

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.

 

Oleksandr_Malof
Altocumulus
Altocumulus

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).

 

Sara_the_Member
Nimbostratus
Nimbostratus

@Krystian_Baniak

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:

https://cdn.f5.com/product/bugtracker/ID1115601.html