|
Hello
On Fri, 2010-10-01 at 00:55 +0200, Julian Anastasov wrote:
> 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?
Yes
>
> > @@ -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?
Yes, the destination network
>
> > 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.
Yes you're right as usual :-)
With "prefered_lft=0" src selection works in most cases now.
So this is not an issue any more.
>
> > 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.
I prefer fl.fl6_dst right now since rt6i_dst gives a bad destination in
many cases.
I will do some more testing before posting the patch.
>
> 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
|
