Re: keep state "issue" / possible feature for the future?

On 2007-03-02 15:18, Tom Ploegmakers rudely top-posted:
> Quoting Jefferson Ogata (Jefferson.Ogata@noaa.gov):
>> Is this (or at least the original poster's issue) not something that is
>> controlled via ip_strict_dst_multihoming?
>
[snip]
> I send a (UDP) request to the address in the other network and the server
> decides to answer via the 'direct' route using an IP address in my network.
> I have to start reading docs, but i think TCP will not do this.

TCP obviously has to respond from the IP address that was the
destination of the connection request. This is handled by the kernel as
part of connection establishment. But the source IP used in reply
traffic is independent of what interface is used to transmit that
traffic. The interface to be used is determined by the routing table,
but ip_strict_dst_multihoming, when enabled, ought to tweak that.

With UDP, there is no connection establishment. It is thus up to the UDP
service to choose what IP address to transmit traffic from. Well-written
UDP services (e.g. BIND, ntpd), create a distinct socket for each
service IP so that they can easily tell which IP was the destination for
a given inbound request datagram, and send response traffic using the
same socket. Again, the actual interface chosen for the response traffic
is determined not by the source IP, but by the destination IP, but
ip_strict_dst_multihoming should control this if the strong ES model is
correctly implemented.

For NFS, there's a good chance you're better off using TCP anyway.

--
Jefferson Ogata <Jefferson.Ogata@noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt@noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service