IPVS-DR problem with neigh lookup in 3.6

IPVS-DR problem with neigh lookup in 3.6

[Julian Anastasov]

	Hello,

	I suspect commit a263b3093641fb1ec377582c90986a7fd0625184
is causing problem for the IPVS Direct Routing mode which
requests output route for real server IP (RIP) but packets
contain virtual IP (VIP). Before 3.6 ip_finish_output2 used
the neighbour address while now we use iph daddr. The
result is that now we send ARP query for VIP instead of RIP.

	Is it a good idea to keep rt_gateway always
valid and to check RTCF_REDIRECTED where needed?
While checking this option I see that the value of
0 is not good for matching, for example, callforward_do_filter
in net/netfilter/nf_conntrack_h323_main.c will fail
too. If we do such change there is a chance some rt_gateway
checks to disappear, other will be replaced with check for
RTCF_REDIRECTED flag. Should I try such option?
Because adding rt_dst does not look good, it will not
help to callforward_do_filter too.

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: IPVS-DR problem with neigh lookup in 3.6

[David Miller]

From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 4 Oct 2012 09:52:47 +0300 (EEST)

> 	Is it a good idea to keep rt_gateway always
> valid and to check RTCF_REDIRECTED where needed?

What exactly do you mean by this?  rt_gateway can only
be explicit nexthop or zero for local subnet.

It cannot take on any other value, otherwise routes are
not properly sharable.

> Because adding rt_dst does not look good, it will not
> help to callforward_do_filter too.

Adding rt_dst is not to be seriously considered.

Re: IPVS-DR problem with neigh lookup in 3.6

[Julian Anastasov]

	Hello,

On Thu, 4 Oct 2012, David Miller wrote:

> From: Julian Anastasov <ja@ssi.bg>
> Date: Thu, 4 Oct 2012 09:52:47 +0300 (EEST)
> 
> > 	Is it a good idea to keep rt_gateway always
> > valid and to check RTCF_REDIRECTED where needed?
> 
> What exactly do you mean by this?  rt_gateway can only
> be explicit nexthop or zero for local subnet.
> 
> It cannot take on any other value, otherwise routes are
> not properly sharable.

	Oh, yes, that was the reason for value 0.

> > Because adding rt_dst does not look good, it will not
> > help to callforward_do_filter too.
> 
> Adding rt_dst is not to be seriously considered.

	OK, I'll think more for alternatives. May be
if there is a way to request output route that should
not be cached. Then we can set valid rt_gateway for
such private routes, fnhe can be used for info too
but this route should not be cached there. Or we
should cache the entry in fnhe, so that we can detect
that fnhe is reclaimed.

	Currently, we handle NETDEV_UNREGISTER
both for cached and uncached routes, so users like IPVS
can safely request such special routes. IPVS does the
rt caching itself.

	Now the question is how to request such host routes
via flowi. Archives remember for FLOWI_FLAG_RT_NOCACHE, may be
we can port it to the new caching as FLOWI_FLAG_RT_HOST?
FLOWI_FLAG_RT_HOST will mean: can cache in fnhe if present
or return uncached result as second option.

	BTW, I see another place with problem, ip_forward():

if (opt->is_strictroute && opt->nexthop != rt->rt_gateway)

	may be should be

if (opt->is_strictroute && opt->nexthop != rt->rt_gateway &&
    rt->rt_gateway)

Regards

--
Julian Anastasov <ja@ssi.bg>