|
Julian,
> Are you using rp_filter protection for eth0 and eth1?
>I'm wondering because you have same subnet on two devices and the
>plain kernels don't handle this. I'm even not sure whether you
>can apply the patches for alternative routes plus hidden-forward_shared,
>I have never tried it (oh, some many patches to sync).
rp_filter=1 for all devices. I can receive replies from the site, as can
most anybody else who hits it.
>> (RIP1) Windows 2000 Server 65.88.136.59 GW 65.88.136.62
>> (RIP2) Windows 2000 Server 65.88.136.58 GW 65.88.136.62
> Everything else is looking good.
Thanks
>> The only thing I could think of is that the request for www.apohiolaw.com
is
>> going out to 65.88.136.60, which the loadbalancer is forwarding to .59
and
>> .58 which is going back to the client with SRCIP = 65.88.136.58 or .59
> Not possible. Nobody changes the addresses for DR.
So what you're saying here is that the Windows servers reply to the client
with a source IP of 65.88.136.60? Ok, I guess I can see that. I figured that
since it was going from the .60 loopback interface to the .59 RIP interface,
it would be sent with .59 Source
> Can you collect some data with tcpdump? Is the problem
>persistent? If somewhere rp_filter=0 then may be you receive the
>packets from the real server on device that you don't expect.
>And may be on this device there is no forward_shared specified.
>This is caused from the fact that when the both NICs (eth0 and eth1)
>are connected to same hub they see the broadcast ARP queries from
>the real servers but the director replies through all these NICs
>without rp_filter protection. It is a race, which of the replies
>the real server receives first.
I'll run tcpdump for the next half-hour and try to find out what I can. If I
can send you the file to look at it would be appreciated. I'm pretty sure
what I'm looking for, but not positive. Since rp_filter is set to 1 though,
all the NICs are being protected right? So then there shouldn't be any ARP
query problems. I think.
Bill Hatter
|
