2011-09-06 07:45 AM
We use a Linux Redhat to manage our filers (FAS 3240, FAS 3160)
Since the upgrade to Ontap 8.0.2P1 we have every week this message when we want to connect in SSH to our filer.
In the Linux Console : ssh_exchange_identification: Connection closed by remote host
In the Putty :
If I go to the system in RLM I see this message in console of the Filer:
gdc00181> Mon AugMon Aug 29 12:50:22 CEST [openssh.session.limit:in 29 12:fo]: Exceeded the maximum allowed ssh sessions: 24.
50:22 CEST [openssh.session.limit:info]: Exceeded the maximum allowed ssh sessions: 24.
The only workaroud found is to reboot the filer
I want to know if somebody have noticed the same problems
Thanks in advance
2011-09-21 12:06 PM
You're not the only one - ssh is the only way we manage our filers, so this puts effectively puts us down until netapp can fix it. This happened after a recent upgrade from 6070->6280s to 8.0.2.p2 (7mode)
I'll reply again if we fix it without a reboot.
2011-09-21 06:26 PM
So, no fix or workaround - apparently OnTap is completely opaque (even to the diaguser systemshell on FreeBSD); killing the sshd process inside of ontap (which is separate from the one running under inetd in systemshell) is impossible. We just went through a hellishly obstructive (paperwork-wise) upgrade of our main netapp filers, and are now going to have to do it again in a few weeks when 8.0.2p3 comes out. This is extremely bad for us, because ssh is the only way we manage the filers. All of our scripts will have to be rewritten temporarily and insecure protocols turned on for us to do anything with these filers.
To anyone else that experiences this issue and finds this thread - don't waste your time with the diaguser for the entire day trying to find a way to fix it like I did! (Or just wait for 8x to become stable if you haven't upgraded yet.)
2011-09-21 11:04 PM
we open a case for that and we had an answer of the support:
it's a bug, here is the burt :
it's corrected in version : ONTAP 8.0.2P2D4
I will try this version and let you know.
2011-09-21 11:21 PM
Thanks for those links - support couldn't provide them. we experienced activity similar to the one in 48407:
<foobar ~> sudo tcpdump -i eth1 'host toaster1'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:17:50.276938 IP foobar.40047 > toaster1.ssh: Flags [S] [...]
00:17:50.277795 IP toaster1.ssh > foobar.40047: Flags [S.] [...]
00:17:50.277813 IP foobar.40047 > toaster1.ssh: Flags [.] [...]
00:17:50.278732 IP toaster1.ssh > foobar.40047: Flags [F.] [...]
00:17:50.279027 IP foobar.40047 > toaster1.ssh: Flags [F.] [...]
00:17:50.279842 IP toaster1.ssh > foobar.40047: Flags [.] [...]
Since this is a minor-rev upgrade, we would be able to do it without taking down the cluster. Let us know how it goes and if you continue seeing symptoms;
2011-09-22 08:11 AM
This is different than the bug where all 24 ssh sessions are locked and can’t be deleted…or might be in this fix but I don’t see it in the fix list.