[OpenAFS] multiple network interfaces in AFS

Mon, 09 Dec 2002 21:46:24 +0100

--------------040403040407020209040106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Warren.Yenson@morganstanley.com wrote:

>>>In practise (on Solaris fileservers), we've seen that when although a
>>>client will connect to qfe1:0, the return packets from the fileserver
>>>have the source address of qfe1, which can fool the RX driver on the
>>>client to continue the rest of the RX exchange to qfe1.  This is despite
>>>using any combination of NetInfo and NetRestrict on the server.
>>>      
>>>
>
>  
>
>>If I understand you correctly, true failover is not possible because the
>>moment the standby machine takes over, some clients will want to "RX
>>echange" with the "real" IP of the default active fileserver. Obviously,
>>you have such a setup. What happens to those clients, do they recover
>>somehow?
>>    
>>
>
>We use a kernel hack which post-sets the IP address of the socket for the
>fileserver to the IP address for qfe1:0.  The kernel is forced into
>thinking that the fileserver opened UDP 7000 with a specific IP address,
>and will use that IP address as the source address on all outgoing UDP
>7000 packets.
>
>  
>
>>Based on which criteria does the fileserver select the interface to
>>return packets, closest IP to the client?
>>    
>>
>
>In our experience, unless we use the hack described above, the interface
>selected is the one indicated by the kernel routing tables.
>  
>
I see, thanks for explaining.
I'd prefer not to use a kernel hack and rather see the NetInfo / 
NetRestrict  have the desired effect you described in the previous post:

>It would be nice to have the fileserver limit the ports that it opens to
>the ones listed in NetInfo / NetRestrict, rather than open them all and
>rely on VLDB and UUID information doing the correct thing.
>
Maybe the OpenAFS developer team considers this a "feature request"? :)
Could one of the developers comment on this, please?

TIA

Regards,
    Marc

--------------040403040407020209040106
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<a class="moz-txt-link-abbreviated" href="mailto:Warren.Yenson@morganstanley.com">Warren.Yenson@morganstanley.com</a> wrote:<br>
<blockquote type="cite"
 cite="midPine.GSO.4.33.0212090922320.14365-100000@curlcurl">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">In practise (on Solaris fileservers), we've seen that when although a
client will connect to qfe1:0, the return packets from the fileserver
have the source address of qfe1, which can fool the RX driver on the
client to continue the rest of the RX exchange to qfe1.  This is despite
using any combination of NetInfo and NetRestrict on the server.
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">If I understand you correctly, true failover is not possible because the
moment the standby machine takes over, some clients will want to "RX
echange" with the "real" IP of the default active fileserver. Obviously,
you have such a setup. What happens to those clients, do they recover
somehow?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
We use a kernel hack which post-sets the IP address of the socket for the
fileserver to the IP address for qfe1:0.  The kernel is forced into
thinking that the fileserver opened UDP 7000 with a specific IP address,
and will use that IP address as the source address on all outgoing UDP
7000 packets.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Based on which criteria does the fileserver select the interface to
return packets, closest IP to the client?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
In our experience, unless we use the hack described above, the interface
selected is the one indicated by the kernel routing tables.
  </pre>
</blockquote>
I see, thanks for explaining.<br>
I'd prefer not to use a kernel hack and rather see the NetInfo / NetRestrict
&nbsp;have the desired effect you described in the previous post:<br>
<blockquote type="cite">
  <pre wrap="">It would be nice to have the fileserver limit the ports that it opens to
the ones listed in NetInfo / NetRestrict, rather than open them all and
rely on VLDB and UUID information doing the correct thing.</pre>
</blockquote>
Maybe the OpenAFS developer team considers this a "feature request"? :)<br>
Could one of the developers comment on this, please?<br>
<br>
TIA<br>
<br>
Regards,<br>
&nbsp;&nbsp;&nbsp; Marc<br>
</body>
</html>

--------------040403040407020209040106--