|
Replying again now that I've got a lot of testing done. I'm heading home soon
so just posting an update and will test the last few things tomorrow. I'll
also try to submit a broken up patch tomorrow so that specific changes and
reasoning can be discussed more easily.
On Saturday 12 April 2008 18:07:59 Julian Anastasov wrote:
> - all forwarding methods can be tested on LAN, even LVS-TUN
Haven't been able to test LVS-TUN yet, but I can't see any reason why it
shouldn't work. Will test tomorrow morning.
> - forwarding of related ICMP traffic (ICMP errors) in both directions,
> for all methods
Tested.
> - ICMP generation to both sides (client and real server): when there is no
> real server, when skb is longer than PMTU.
I tested the no real server case. How can i test the skb-too-large case? I
tried changing the MTU on the director's interface on the real-server side,
but traffic continued to pass fine...
> - scheduling by nfmark
Tested.
> - firewall: at least basic packet fields matching
iptables -t filter -A FORWARD -d 192.168.0.7 -i eth0 -j ACCEPT
iptables -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -P FORWARD REJECT
where 192.168.0.7 is the VIP I'm testing with worked fine. Pretty much any
firewall rules should work fine as I've moved LVS hooks to the points of
entry/exit of the netfilter flow.
> - ip_vs_ftp testing (LVS-NAT) when netfilter ftp module is in
> effect: test if double NAT happens resulting in broken packets (TCP
> sequence numbers or payload) when payload is changed if IP:PORT
> strings in FTP commands have different length (VIP and RIP).
Tested plain LVS-NAT as well as with SNAT and DNAT. Surprisingly, it works
even with the above conntrack-based filter in place. I think that indicates
that double NAT is happening (else RELATED wouldn't match) but with the order
that hooks are called things don't get screwed up - I think. I'll investigate
this a little further.
> > * IP_VS_CONN_F_BYPASS - what is this?
>
> IP_VS_CONN_F_BYPASS is used for transparent proxy setups when
> real server (cache server) is not present and we should forward the
> traffic to original destination. The idea is request still to be served.
> In such case IPVS traffic uses the original destination instead of real
> server.
Not tested yet. I assume I just need to add a real server with the same
IP/port as the virtual server?
> There are some issues that prevent IPVS to benefit from Netfilter
> connection tracking:
>
> - Netfilter's NAT and routing are not in single place (hook), difficult to
> handle LVS-DR
LVS-DR with real server as a client using SNAT... Will test this tomorrow too.
> - Netfilter can re-route sometimes (eg. after mangle), it can cause
> properly routed LVS-DR traffic to fail.
I don't understand exactly what you mean by this. It could only happen if the
user sets rules that causes it to happen right?
> - Double NAT for ip_vs_ftp
Addressed above.
--
Jason Stubbs <j.stubbs@xxxxxxxxxxxxxxx>
LINKTHINK INC.
東京都渋谷区桜ヶ丘町22-14 N.E.S S棟 3F
TEL 03-5728-4772 FAX 03-5728-4773
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
