|
Hello,
On Tue, 7 Nov 2000, David D.W. Downey wrote:
> I _do_, however, have a question regarding routing from the web servers that
> may or may not affect the packets managed under the auspices of the lvs
> daemon.
>
>
> OK, right now the web servers have to feed all information they send or
> receive through the backend VIP on the front end node(s). To lessen the
> amount of traffic passing through the 192.168.1.254 backend VIP I would like
> to place route entries into the webfarm members' routing tables. AKA, I want
> to send all the 10.10.10.0 traffic that the webservers generate while
> talking to the backend request processors (on the 10.10.10.0 network)
> through the 192.168.1.250 interface on the Linux router box.
I don't understand well the setup but read the below rules.
> Normally this would be as simple as adding a route -net 10.10.10.10 netmask
> 255.255.255.0 gw 192.168.1.250 command to the web servers' startup scripts.
> I have not added this command yet as these are production servers that I can
> not have down even for a momentary goof, such as my belief that this should
> NOT affect things turns out to be wrong.
>
> Will adding the extra routing statement to the web farm members cause
> routing issues with the LVS?
> If so what, and is there a way, convoluted or not, to allow this?
>
> Basically what's happening is that everything needed to generate the
> information returned to the requestor coming in on the front-end VIP is
> generated on the 10.10.10.0 network, fed to the webfarm member requesting
> the info and then repackaged for delivery to the outside requestor. Right
> now all this traffic passes through the 192.168.1.254 backend VIP. We don't
> want that.
>
> Any help would be appreciated.
Read this good explanation from tc lewis:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=97312015130286&w=2
The main points are:
- a real server configured with NAT method can use many kinds of routing
rules to return the answer through the gateway they come from:
- the masq box is default gateway for the real server: this is
the default method that many people use
- source routing: this method allows the real servers to receive
requests from many masq boxs and to return the answers
selecting the next gateway based on the address used:
masq1 masq2
\ /
\ multihomed /
real server
192.168.0.n 192.168.1.n
ip rule add prio 100 from 192.168.0.0/24 table 100
ip rule add prio 101 from 192.168.1.0/24 table 101
ip route add table 100 0/0 via 192.168.0.1 dev eth0
ip route add table 101 0/0 via 192.168.1.1 dev eth0
- a real server configured with DR method can't use the LVS director
as gateway for the answers. The Linux kernel does not allow packets
with saddr=local_director_address, i.e. VIP, to be forwarded to the
client. This is treated as spoofing. This problem can be solved
with a kernel patch.
Considering these examples you can build different setups.
And don't go in production without testing :)
> ---
> DAVID D.W. DOWNEY SENIOR LINUX SYSTEMS ADMINISTRATOR
> QIXO, Inc. Home Page =
> http://QIXO.com
> 2192 Fortune Drive Company Email =
> ddowney@xxxxxxxx
> San Jose, CA 95131 Company Phone = +1
> (408) 514-6441
> USA Company FAX =
> +1 (408) 516-9090
> ---
Regards
--
Julian Anastasov <ja@xxxxxx>
|
