Hello, On Wed, 29 Sep 2010, Hans Schillstrom wrote:
Hello I think this patch should be stopped since it doesn't work in some cases.
I think, the patch is still correct. May be we just need to create new patch to fix the remaining problems which are old (rt6i_dst use).
There is also a bug in the patch. ip6_route_output() returns a key as dest address which can be a network and that's not a good dest address. (It can be seen if the tunnel remote endpoint has to pass through an router/gateway)
You are referring to rt6i_dst?
@@ -750,8 +763,8 @@ ip_vs_tunnel_xmit_v6(struct sk_buff *skb ... ... - ipv6_addr_copy(&iph->daddr, &rt->rt6i_dst.addr); + ipv6_addr_copy(&iph->daddr, &cp->dest->addr.in6);
I prefer not to risk with cp->dest, see below. May be ipv6_addr_copy(&iph->daddr, &cp->daddr.in6); is safer. But we still can add more checks for the daddr type one day when backup supports IPv6. - both rt6_alloc_cow and rt6_alloc_clone copy our fl->fl6_dst into rt6i_dst. Only that CLONE_OFFLINK_ROUTE is not 1 and I'm not sure what happens with rt6i_dst in this case (ip6_pol_route). May be you see the route prefix there as set by ip6_route_add?
The principle for it is wrong, it's more or less impossible to get the expected address from ipv6_get_saddr_eval(), depending on your network topology. Since there must be an address set on the remote/local pair for a IPv6 tunnel and you can't predict what source address you will get the function is more or less useless.
Yes, for IPv6 I don't see option in tunnel to accept traffic from any remote address. This was not the case with IPv4. But the source address selection is rich enough. I don't know for any example settings for IPVS on IPv6 but routes in IPv6 can have source address if CONFIG_IPV6_SUBTREES is defined (ip6_route_add). Still, the routing should be able to return valid source address. I don't know what settings you are using but looking at code I think the options are: - assign source address for route - add VIPs as deprecated addresses (prefered_lft=0). By this way we don't risk they to be autoselected as source in output routes because they are ignored in ipv6_get_saddr_eval at step IPV6_SADDR_RULE_PREFERRED As result, the source address should be properly selected and our patch looks ok for the saddr part.
After spending a day single stepping through the IPv6 stack I'm more or less sure that: - The only way to get IPv6 tunnels to work in a predictable way is to add a "tunnel source address" to the ipvsadm commad.
This is not possible for the case when cp->dest is NULL, eg. when connection using fwmarks is moved to backup server. But this does not happen because IPv6 is not supported for sync. If one day we add support in new sync format I'm sure there will be also fwmark and cp->dest will be valid for the tunneling method.
What to do ? - add a --tunsrc switch to ipvsadm -i command ? or - Disable the IPv6 tunnel mode ? or - Leave it as is ?
This 3th option is better for the moment. I think, saddr is selected correctly, see ip6_dst_lookup() and ip6_dst_lookup_tail() in net/ipv6/ip6_output.c But if you think using ipv6_addr_copy(&iph->daddr, &cp->daddr.in6); is working then feel free to post a patch on top of the previous patch. Because other code in kernel uses resulting fl.fl6_dst, not rt6i_dst. 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
