On Wed, Jul 14, 2021 at 11:38:15AM +0200, Tom K wrote: > > > > but why? If I reboot the other node, the system become MASTER. > > > > That is because the other system stops sending carp announcements > > when you reboot it. This is unrelated to the demote counter. The demote > > counter only matters as long as another carp MASTER remains visible. > > A forced failover like this could break active connections. > > > > The pfsync interfaces adds 32 to the carp demote counter when it comes > > up, > > and it removes 32 from the demote counter once it has obtained an > > up-to-date > > copy of the state table, which can take some time. > > > > This prevents the box from becoming MASTER while it may not yet know > > about all the currently active connections. > > > > But why the 1st system is switchback to BACKUP if the 2nd system is Up > again? Normaly 1st should stay MASTER, because at this time, the 1st one > have the most recent state table which should be now send to the 2nd one. > Yes, it's because of the higher demotioncount then the 2nd system, but if > the 1st one standalone, it should self demoted to 0/1 bei pfsync because > there is no other system? > > I wait more then an hour, but the system is still on 33. So it seems the > state table is never synced completly, but if I compare both with "pfctl -s > state" they look are in sync - strange. > > I never had this issue and we use a lot of cluster setups like these in the > past.
Yes that doesn't seem right. If you have the net.inet.carp.preempt sysctl set then the machine with a lower adskew value should move into BACKUP, provided the demote count is equal. But if the demote count is not equal then of course the machine with a higher demote count will remain in BACKUP state. If the demote count never drops then perhaps pfsync traffic isn't passing properly?
