|
Hello,
On Fri, 16 Nov 2001, Bill Hatter wrote:
> >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.
Then I assume eth0/forward_shared is 1.
> >> (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
The RSs reply with the VIP
> since it was going from the .60 loopback interface to the .59 RIP interface,
> it would be sent with .59 Source
No
> 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.
Yes, no ARP flux expected, until you use 65.88.136.62 to
talk to other hosts on the LAN through both eth0 and eth1. You have to
tell us whether this is a persistent problem or happens in rare cases.
Also you better to monitor the ARP tables with arp -an. You can also show
us all IP addresses and routes in director or everything is shown in the
first posting?
> Bill Hatter
Regards
--
Julian Anastasov <ja@xxxxxx>
|
