Re: moving ipvs() to POST/PREROUTING

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Filesystem Devel]     [Linux NFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [X.Org]

  Powered by Linux