|
Hello,
On Tue, 28 Jan 2003, Nicolas Chiappero wrote:
> |
> (ROUTER)
> ____|_____
> | | eth0: public FW IP address
> | FIREWALL | proxy arp (2.2 kernel) for VIP to DIP
> |__________| eth1: private FW IP address = FIP
> ____|_____
> | | VIP=XXX.XXX.XXX.XXX (eth0:1)
> | DIRECTOR | GW = FIP
> |__________| DIP=192.168.0.1 (eth0)
> |
> -----------------------------------
> | | |
> RIP1=192.168.0.2 RIP2=192.168.0.3 RIP3=192.168.0.4 (all eth0)
> VIP on lo:1 for all RIPs
> _____________ _____________ _____________
> | | | | | |
> | realserver | | realserver | | realserver |
> |_____________| |_____________| |_____________|
>
> GW for all RIPs is FIP.
>
> I would like to merge director and firewall into only one box, but
> some questions remain and I have no clear answers :
> - I read many different documents and figured out that "proxy arp"
> is equivalent to "transparent proxy". Am I right ?
No, the both terms are used in different contexts:
- proxy ARP is used when the traffic should be routed at Layer 3
with the help from ARP. The packets reach the routing after the
box answers ARP probes asking for foreign addresses.
- transparent proxy has mostly Layer 5-7 semantic, it is used
to intercept traffic destined to foreign addresses and to deliver
it to sockets.
> - If so, I found a document (http://www.sjdjweis.com/linux/proxyarp/)
> explaining how to do proxy arp on a 2.4 kernel. Will this method
> be compatible with LVS as long as director would also be the default
> GW for realservers ?
No. The spoofing checks performed from routing will drop
the traffic.
> On the other side, I found some explanations by Julian in LVS-HOWTO
> chapter 14.4.2 explaining how to patch director kernel to manage source
> martian packets.
> Both solutions works ?
Solution 1:
You can use Linux Bridging. In such case the traffic from
real servers to the ROUTER passes only Layer 2, i.e. the routing
is not reached and you avoid the spoofing checks. If you don't
want Bridging or the link to the ROUTER is not ARP aware, then
you can use solutions that avoid the spoofing checks for this
traffic. One of them is the forward_shared flag (Solution 2).
> I would like to have a very stable setup, so I'm wondering whether
> switching from LVS-DR to LVS-NAT would be a better approach or not.
> In this case, I would like to be sure that LVS-NAT can handle
> the actual load of this LVS-DR setup. Can I do some maths
> against actual ipvsadm statistical values ?
The difference in the NAT/DR speed is very small in Linux 2.4,
nearly nothing. My recommendation is:
- DR or NAT (depending on other factors, mostly real server setup
complexity)
- forward_shared: 1 in all/forward_shared and in eth1/forward_shared,
assuming eth1 is the private interface.
> Regards,
> Nicolas.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
