David.Lee at ecmwf
May 1, 2012, 8:50 AM
Post #3 of 5
(979 views)
Permalink
|
Many thanks, Stuart.
The NetApp belongs to another part of the organisation (not my part) and
the organisation is very new to NetApp. The reason I, rather than they,
were asking the question here is because in my previous life elsewhere I
had looked after NetApps, so I was already familiar with "toasters".
(Naturally, I'll be recommending my colleagues to get familiar with this
list!)
Regarding the particular technical question, it seems there's no obvious
quick setting, so we'll probably simply opt for the application level
work-around (which is still reasonably clean for us to do).
Thanks again.
-- David Lee
Stuart Kendrick wrote:
> Hi David,
>
> For what it is worth, I tried replicating this in our environment while
> capturing traffic:
> telnet toaster 50
> vs
> telnet toaster 5050
>
> In the first case (Frame #1-#3), the NetApp doesn't answer the TCP SYN
> packets from my client. TCP sends one SYN, stalls for 3 seconds, sends
> another SYN, stalls for 8 seconds, sends a third SYN, stalls again, then
> gives up.
>
> In the second case (starts with Frame #4), the NetApp responds
> immediately with a TCP RST. [.The 'SH...' host is the client; the
> 'RU...' host is the NetApp.] The client tries three times and ONTAP
> Resets each time.
>
>
>
> Here the behaviors of a handful of operating systems:
> Windows: Silence for both upper and lower ports
> Linux/Solaris/OpenVMS: TCP RSTs for both upper and lower ports
> ONTAP: TCP RSTs for upper ports; Silence for lower ports
>
> So, I think your question can be refined as follows:
> Is there an Option which changes the TCP stack's behavior, such that
> it issues a TCP RST for all TCP Ports (on which no daemon is listening),
> not just for the upper ports?
>
> You might poke through the output of the CLI command 'options' ... I'm
> not hopeful though ... I don't see anything promising:
>
> options | grep tcp
>
> cifs.netbios_over_tcp.enable on
> ftpd.tcp_window_size 28960
> ip.tcp.batching.enable on (value might be overwritten in takeover)
> ip.tcp.newreno.enable on (value might be overwritten in takeover)
> ip.tcp.sack.enable on (value might be overwritten in takeover)
> ndmpd.tcpnodelay.enable off
> nfs.tcp.enable on
> rpc.mountd.tcp.port 4046
> rpc.nlm.tcp.port 4045
> rpc.nsm.tcp.port 4047
> rpc.pcnfsd.tcp.port 4048
>
> --sk
>
> Stuart Kendrick
> FHCRC
>
>
> On 4/30/2012 3:23 AM, David Lee wrote:
>> A TCP connection towards an arbitrary high port number (>=1024) on the
>> NetApp seems to return "connection refused" instantly.
>>
>> By contrast, a connection towards a low port number waits for several
>> minutes, then something times out. I imagine this is related to
>> assisting security etc.
>>
>> As part of our transition from our previous non-NetApp fileserver, it
>> would be very useful if we could persuade the NetApp to return a quick
>> "connection refused" on a particular low port number. But we cannot see
>> a way to adjust this behaviour (either for a particular low port or for
>> all low ports). Is this possible? If so, could you point us to the
>> relevant documentation, please?
>>
>> (If it is not possible, we can probably put a workaround in the external
>> application.)
>>
>> -- David Lee
>> _______________________________________________
>> Toasters mailing list
>> Toasters [at] teaparty
>> http://www.teaparty.net/mailman/listinfo/toasters
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Toasters mailing list
> Toasters [at] teaparty
> http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters
|
heagfbie.png
