1
22.7 Legacy Series / Re: High availability sync appears to have stopped working but CARP still fine
« on: December 31, 2022, 04:58:28 am »
Glad it worked out. *High Five* 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
22.7 Legacy Series / Re: High availability sync appears to have stopped working but CARP still fine
« on: October 29, 2022, 10:02:30 am »
I rolled back again (22.1.10) and then upgraded again, and everything was still broken, but the error changed from the parsing error mentioned in the other post to host down now.
I disabled and renabled the interfaces on both the opnsense and vmware sides, and everything is working on 22.7.6.
Log into the console and run this:
# /usr/local/etc/rc.filter_synchronize
Whats the output?
I disabled and renabled the interfaces on both the opnsense and vmware sides, and everything is working on 22.7.6.
Thanks for the suggestion. Yes, there is. This is a previously working config that appears to have stopped working at some point. I did have to reinstall the primary server at one point and did so using the USB stick config transfer method. No passwords have changed. The problem is that the diagnostic message I'm getting is so non-specific as to leave me lost as to how to even investigate what's not working.
Log into the console and run this:
# /usr/local/etc/rc.filter_synchronize
Whats the output?
3
22.7 Legacy Series / Re: High availability sync appears to have stopped working but CARP still fine
« on: October 23, 2022, 01:10:38 pm »
I am seeing this same issue after upgrading from 22.1 to 22.7.6. It actually looks like everything is working still and the fail over works, its just something with the sync.
This seems to be related to this issue here:
https://forum.opnsense.org/index.php?topic=29521.0
I was able to repeat the issue rolling back to snapshots I had, happens every time I upgrade to 22.7.6.
This seems to be related to this issue here:
https://forum.opnsense.org/index.php?topic=29521.0
I was able to repeat the issue rolling back to snapshots I had, happens every time I upgrade to 22.7.6.
4
18.1 Legacy Series / Re: [SOLVED] CARP won't become MASTER, both systems always BACKUP
« on: February 08, 2018, 02:56:55 pm »
I just switched from a single pfSense machine to HA OPNsense on a pair of R610s and saw the exact same behavior with ESXi 6.5.
Another thing I found out, I like to present 1 vNic to the server, while using 2 physical uplinks on the esxi side. This way if fail over occurs, ESXi handles it via the built in NIC teaming and it's transparent to the VM. However the NIC teaming introduces another issue. As soon as I plugged in the 2nd sets of cables the interfaces went hard down and stayed in the Backup state.
Long story short if you are going to run this on ESXi do exactly what was said, set the vSwitches to allow promiscuous mode, MAC address changes, and forged transmits and then change Net.ReversePathFwdCheckPromisc to 1, reboot ESXi, and you should be money.
I have been incredibly happy with this setup since then
Helpful links:
http://www.blissfulidiot.com/2013/11/using-carp-with-vmware-esxi.html
https://kb.vmware.com/s/article/2144849 (<--- Confirms this is an expected behavior of ESXi)
Another thing I found out, I like to present 1 vNic to the server, while using 2 physical uplinks on the esxi side. This way if fail over occurs, ESXi handles it via the built in NIC teaming and it's transparent to the VM. However the NIC teaming introduces another issue. As soon as I plugged in the 2nd sets of cables the interfaces went hard down and stayed in the Backup state.
Long story short if you are going to run this on ESXi do exactly what was said, set the vSwitches to allow promiscuous mode, MAC address changes, and forged transmits and then change Net.ReversePathFwdCheckPromisc to 1, reboot ESXi, and you should be money.
I have been incredibly happy with this setup since then
Helpful links:
http://www.blissfulidiot.com/2013/11/using-carp-with-vmware-esxi.html
https://kb.vmware.com/s/article/2144849 (<--- Confirms this is an expected behavior of ESXi)
Pages: [1]