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)

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|(
> --------
>    |
> --------(VIP)
> |LVS-DR|<------------|
> --------             |
>    |(DIP)            |
>    |>----->----      |
>       |(RIP1) |(RIP2)|
>     ------ ------    |
>     |Web1| |Web2|    |
>     ------ ------    |
>       |       |      |
>       |--->------>----
> (VIP)  Linux 2.4.5 eth0
> (DIP)  Linux 2.4.5 eth1:110 GW

        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 GW
> (RIP2) Windows 2000 Server GW

        Everything else is looking good.

> There is an eth1 in the server as well, and it is configured for
> 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 is
> going out to, which the loadbalancer is forwarding to .59 and
> .58 which is going back to the client with SRCIP = 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


Julian Anastasov <ja@xxxxxx>

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