On 13 September 2010 22:17, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
> On Mon, 2010-09-13 at 22:13 +0100, JL wrote:
>> ...I am familiar with the scenario you are describing - where each
>> machine decides the other should handle the connection - but it is not
>> the situation that is occurring at the moment. This problem didn't
>> happen with the exact same setup under 220.127.116.11, and...
> Then might I recommend an Occam's Roazor approach to this? Compile a
> number of kernels from the one which worked up to the one which doesn't.
> Reboot the backup; test; if it doesn't happen then you know the change
> cam later than the kernel you're running.
I intend to do that.
>> Thanks, but I don't think we have cracked it yet. (However, for
>> thoroughness, I will remove the fwmark rules on the backup, as you
>> suggested, and report back.)
> Not the fwmarks! For completeness I meant "clear out the IPVS rules on
> the backup but leave the modules loaded".
OK, tried that:
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
... And I can still trigger the problem.
If I remove the fwmark rules instead, I still get the problem.
> Please read the documentation before posting - it's available at:
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users