Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Netapp: toasters

Getting a quick "connection refused"

 

 

Netapp toasters RSS feed   Index | Next | Previous | View Threaded


David.Lee at ecmwf

Apr 30, 2012, 3:23 AM

Post #1 of 5 (2775 views)
Permalink
Getting a quick "connection refused"

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


skendric at fhcrc

Apr 30, 2012, 6:31 AM

Post #2 of 5 (2741 views)
Permalink
Re: Getting a quick "connection refused" [In reply to]

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
Attachments: heagfbie.png (29.1 KB)


David.Lee at ecmwf

May 1, 2012, 8:50 AM

Post #3 of 5 (2763 views)
Permalink
Re: Getting a quick "connection refused" [In reply to]

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


johnpc at xs4all

May 2, 2012, 8:26 AM

Post #4 of 5 (2693 views)
Permalink
Re: Getting a quick "connection refused" [In reply to]

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 [at] xs4all>
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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters


andrey.borzenkov at ts

May 2, 2012, 9:05 AM

Post #5 of 5 (2700 views)
Permalink
RE: Getting a quick "connection refused" [In reply to]

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 [at] teaparty [toasters-bounces [at] teaparty] On Behalf Of Jan-Pieter Cornet [johnpc [at] xs4all]
Sent: Wednesday, May 02, 2012 19:26
To: David.Lee [at] ecmwf
Cc: toasters [at] teaparty
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 [at] xs4all>
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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Netapp toasters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.