LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-DR and Road Runner (aka. Cable Modems)

To: Bill Hatter <bhatter@xxxxxxxxxxxxx>
Subject: Re: LVS-DR and Road Runner (aka. Cable Modems)
Cc: Lvs <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 16 Nov 2001 16:41:15 +0200 (EET)
        Hello,

On Fri, 16 Nov 2001, Bill Hatter wrote:

> Has any dealt with an issue similar to this?
>
> We have two production Web/FTP Servers behind the loadbalancer. Our
> customers who try to access with Road Runner Cable Modems are having
> problems getting to our website. They get a "page cannot be displayed"
> error.
>
> Here is our LVS-DR layout
>
> --------
> |Router|(65.88.136.33)-------INTERNET
> --------
>    |
> --------(VIP)
> |LVS-DR|<------------|
> --------             |
>    |(DIP)            |
>    |>----->----      |
>       |(RIP1) |(RIP2)|
>     ------ ------    |
>     |Web1| |Web2|    |
>     ------ ------    |
>       |       |      |
>       |--->------>----
> (VIP)  Linux 2.4.5 eth0     65.88.136.60
> (DIP)  Linux 2.4.5 eth1:110 65.88.136.62 GW 65.88.136.33

        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).

> (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.

> There is an eth1 in the server as well, and it is configured for 192.168.1.3
> which the Windows 2000 Web Servers have as well, but are not configured for
> the web service.
>
> 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.

> instead of .60 which would cause a cache/proxy/firewall to stop the packets
> as unauthorized.
>
> Anyone have any ideas?

        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.

> Thanks,
>
> Bill Hatter
> Web/Network Administrator
> Anderson Publishing Company
> Cincinnati, OH


Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>