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
