Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed

[Patrick McHardy <kaber@trash.net>]

Simon Horman wrote:
> On Mon, May 14, 2007 at 07:41:48PM +0200, Patrick McHardy wrote:
> 
>>So you're adding a local route for non-local destination and the
>>address selection in icmp_send() uses the original destination
>>address as source because the route has RTCF_LOCAL set, resulting
>>in an error in ip_route_output_slow().
> 
> 
> I'm not entirely sure that "adding a local route" is the right
> terminology, but then again, perhaps I'm missunderstanding exactly
> what that means.

It means adding a route to the local table, which causes the
resulting dst_entry to be marked with RTCF_LOCAL.

> My undersanding of the problem is that IPVS likes to send icmp to notify
> end-users when real-servers are down. The source ip of such icmp is the
> VIP, that is the IP address associated with the virtual service.
> However, it is quite valid for this VIP not to be configured on the
> machine that is running IPVS. Thus the machine in question wants to send
> icmp packets with a non-local source address.
> 
> http://archive.linuxvirtualserver.org/html/lvs-users/2007-01/msg00109.html
> 
> I think that your patch looks good, assuming that inet_addr_type(VIP)
> is going to return RTN_LOCAL (except in the unlikely case that VIP is
> multicast or something silly like that.

I'm not familiar with the IPVS terms, but as far as I understand,
it is _not_ going to return RTN_LOCAL, so we get the desired
behaviour of selecting a local address as source.

> However, I wonder if efficiency or safety reasons it might
> be better for IPVS to pass some sort of OK_ITS_SUPPSED_TO_BE_NON_LOCAL
> flag into ip_route(). 
> 
> Just a thought.

I'm not too thrilled about adding a route flag when it really is
ICMP address selection that is the problem here.

The patch should be completely safe since multicast and broadcast
packets are already filtered out earlier and the RTN_LOCAL test
matches exactly what ip_route_output_slow does.