hello,
I doubt the problem lies in your setup, I found the master-active
problem, diff below should correct that, can you tell me if it helps?
Index: netinet/ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving
On 2015 Apr 28 (Tue) at 11:36:00 +0200 (+0200), Martin Pieuchot wrote:
:Hello Johan and thanks for your great report!
:
:On 27/04/15(Mon) 11:54, Johan Huldtgren wrote:
: If you try 1.250 and 1.253 and tell me if you can reproduce the problem
: that would be really helpful. In case you see
Hello Johan and thanks for your great report!
On 27/04/15(Mon) 11:54, Johan Huldtgren wrote:
If you try 1.250 and 1.253 and tell me if you can reproduce the problem
that would be really helpful. In case you see something weird, Could
you include the routing table netstat -rnf inet in your
On 24/04/15(Fri) 21:21, Johan Huldtgren wrote:
a few hours after I sent the previous e-mail the backup
(April 23rd snap) took over and became the master, at
that point I could not reach the carp interfaces anymore.
Reverting roles so the host running the April 12th snap
became the master
hello,
If you try 1.250 and 1.253 and tell me if you can reproduce the problem
that would be really helpful. In case you see something weird, Could
you include the routing table netstat -rnf inet in your report? If
you can also play with tcpdump on the various pseudo-interfaces and see
if
hello,
a few hours after I sent the previous e-mail the backup
(April 23rd snap) took over and became the master, at
that point I could not reach the carp interfaces anymore.
Reverting roles so the host running the April 12th snap
became the master would mostly fix the problems although
hello,
I noticed some carp weirdness and sthen@ thought it might be worth
bringing to light. Quick background, I run two carp nodes, one
(current master) is running the April 12th snapshot, the other is
running the April 23rd snapshot. The node running the April 23rd
snap when it's the backup
