Hello, On Wed, 16 Apr 2008, Jason Stubbs wrote: > On Tuesday 15 April 2008 15:41:17 Jason Stubbs wrote: > > I am also not certain of how traffic control will handle this. This > > patch may be causing traffic to be accounted for twice depending on when > > tcp_output is actually run. > > I got confused between TCP congestion control and qdiscs here. Congestion > control is before netfilter and thus unaffected. Qdiscs run directly on > interfaces after netfilter has completed and so is also unaffected. Yes, QoS is before (ingress) and after (egress) any IP hooks. No TCP and sockets (skb->sk) when playing with IPVS. When IPVS runs you should take care for such issues: - do not play with packets accounted for sockets (skb->sk != NULL). There was check you removed. Please, reconsider. - ability to throttle IPVS traffic with netfilter modules. How we can benefit from such modules, can they protect us, can we avoid IPVS scheduling on overload (such modules should work before IPVS conn scheduling, which should be true if you schedule in POST_ROUTING). Was true for LOCAL_IN scheduling. - any work before input routing is dangerous (eg. PRE_ROUTING). There can be spoofed or looped traffic. For example, it is safer to work with replies, OTOH handling requests before input routing should be considered dangerous. - one thing should be checked: what state is shown in Netfilter when UDP and TCP packets are scheduled. I see that at POST_ROUTING ipv4_confirm() is called, then __nf_conntrack_confirm() calls nf_ct_get() which should work with translated addresses (by IPVS). You should see that netfilter correctly marks traffic as confirmed. Also, you can confirm that states are properly set by applying NEW rules for requests and then only ESTABLISHED,RELATED in FORWARD. I think, you once tested it with -m state rules but make sure it works after recent (any new) changes because this is essential part. It is interesting what is -m state in Netfilter when no replies are forwarded for LVS-DR setups, replies go directly from real server to client. Are you sure long established connections do not timeout shorter due to bad state in netfilter? May be conntrack_tcp will be confused that only one direction works? - when testing LVS-NAT make sure client does not see directly the internal hosts. This can happen when testing on LAN. It is possible something to work on LAN but not when client is out of LAN because sometimes packets do not flow as expected but client and real servers still talk successfully by avoiding IPVS box. No reply traffic passes IPVS box and nothing is REJECT-ed in FORWARD. But it should be noticed by broken TCP connections, I think. - there are setups that use LVS-DR but replies come in IPVS box because it is gateway for the real servers. This is useful feature because VIP is preserved in packet allowing virtual hosts to work by IP. It means replies should be passed in IPVS box with the help from forward_shared patch. - ICMP generation: when VIP is not configured as IP address icmp_send() currently will use some local address as source for the ICMP error sent to client. Even if this is not a big problem for clients out of LAN, on some setups when non-Linux clients are on LAN this can be confusing, there are expectations that multiple subnets share single LAN without a problem (clients know only the VIP subnet, for example). But this is more an icmp_send() problem. Regards -- Julian Anastasov <ja@xxxxxx> -- 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
