|
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
| 