Yoann Juet wrote:
Pablo Neira Ayuso wrote:
Pablo Neira Ayuso wrote:
Please, add the following line here to your scripts:
conntrackd -B -C /etc/conntrackd.conf
Let me now if that fixes your problem.
Updates? I'm intrigued with your problem. Some more info for
troubleshooting. You have the commands:
display internal cache (states that belong to this node)
# conntrackd -i
display external cache (states that belong to other nodes)
# conntrackd -e
While trigering fail-overs, you should see the same states in the
active's internal cache and the backup's external cache. If that does
happen, there's a problem somewhere.
I'm about to release 0.9.11 but before I'd like to close pending issues.
The issue is solved by adding "conntrackd -B" to my script. According to
the logs, such instruction sends bulk update. What is it for exactly ?
It forces the new primary to send a bulk update with the current state
(that has been injected into the kernel) to the backup. You were using
heartbeat? It seems that heartbeat triggers the backup state transition
(thus, the request to resync to the new primary) before the new primary
is itself in sync.
BTW, this change in the primary-backup.sh script has been already
included in the conntrack-tools 0.9.11 (that I release a couple of days
ago).
--
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
