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
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@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
FYI. I tried replicating in my environment, and our toaster returns an immediate 'connection refused' for any portnumber, above or below 1024, doesn't matter.
Are you sure you aren't talking to some default firewall somewhere? Maybe run a test from a host that is connected to the same VLAN as the toaster.
(Ontap 7.3.6, if that matters).
On 05/01/2012 05:50 PM, David Lee wrote: [...]
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?
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.
I confirm this on 8.x. I do not think there is any easy to change it. The best bet is to probably open support case and try to convert it into change request. ________________________________________ From: toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] On Behalf Of Jan-Pieter Cornet [johnpc@xs4all.nl] Sent: Wednesday, May 02, 2012 19:26 To: David.Lee@ecmwf.int Cc: toasters@teaparty.net Subject: Re: Getting a quick "connection refused"
FYI. I tried replicating in my environment, and our toaster returns an immediate 'connection refused' for any portnumber, above or below 1024, doesn't matter.
Are you sure you aren't talking to some default firewall somewhere? Maybe run a test from a host that is connected to the same VLAN as the toaster.
(Ontap 7.3.6, if that matters).
On 05/01/2012 05:50 PM, David Lee wrote: [...]
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?
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.
-- Jan-Pieter Cornet johnpc@xs4all.nl SSL is only keeping your connection safe from hackers, crooks and three letter agencies by the least secured, least likely to refuse money from strangers, and least bullying-proof of several hundred companies worldwide.
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Borzenkov, Andrey -
David Lee -
Jan-Pieter Cornet -
Stuart Kendrick