SSH_CONNECTION_CLOSE(l) constantly in my syslogs from A5800s (186 Views)
Reply
Advisor
MDella
Posts: 22
Registered: ‎10-20-2012
Message 1 of 2 (186 Views)

SSH_CONNECTION_CLOSE(l) constantly in my syslogs from A5800s

Well, I seem to constantly get the following in my logs as long as someone is connected to one of the A5800 switches:

 

Jul 18 09:47:29 SPT-RTR1.pod1.prod %%10SSH/6/SSH_CONNECTION_CLOSE(l): -DevIP=192.168.1.8; STEL user  (IP: 172.24.192.16) logged out because the SSH client closed the connection.
Jul 18 09:47:29 SPT-RTR1.pod1.prod %%10SSH/6/SSH_CONNECTION_CLOSE(l): -DevIP=192.168.1.8; STEL user  (IP: 172.24.192.16) logged out because the SSH client closed the connection.
Jul 18 09:47:29 SPT-RTR1.pod1.prod %%10SSH/6/SSH_CONNECTION_CLOSE(l): -DevIP=192.168.1.8; STEL user  (IP: 172.24.192.16) logged out because the SSH client closed the connection.

There are thousands of these entries every few seconds while someone or something is logged into the switch.  Doesn't seem to matter which SSH server is making the connection (putty, securecty, openssh, solaris ssh, another switch), the logs keep filling up.

 

Additionally, at random the switch drops the SSH connection:

 

[SPT-RTR1.pod1.prod]Connection to 192.168.1.8 closed by remote host.
Connection to 192.168.1.8 closed.
[mdella@catalyst ~]$

 


It has nothing to do with timeouts, etc. I could be in the middle of typing something and get disconnected.  It appears random.  From a L3 point of view, there is nothing between the ssh client and ssh server.  From an L2 point of view it does go through a A7506 (two of them IRF'd together) from the server to the A5800 (leaf) switch.

 

Anyone have clues or seen this behaviour before?

 

Marcos

 

Please use plain text.
Esteemed Contributor
paulgear
Posts: 655
Registered: ‎04-03-2011
Message 2 of 2 (168 Views)

Re: SSH_CONNECTION_CLOSE(l) constantly in my syslogs from A5800s

Hi Marcos,

One thing i've seen cause similar behaviour to this is duplicate IP addresses. If you have a Linux box handy, installing arpwatch and seeing if it notices any duplicates is a good way to gain information about this.

That's not the only solution of course, but i would certainly try to rule it out before chasing down any other issues.
Regards,
Paul
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation