[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1951
  • Last Modified:

Telnet/SSH session gets hanged

Hello Experts,

We recently migrated our network from Frame Relay to MPLS. After the migration, we are facing problem with Telnet/SSH session gets hanged when leave it idle for sometime (say 10 to 20 minutes). So everytime we need to reconnect to the server or we need to keep the session active always by pressing some key.
To resolve this issue, we have escalated to our ISP but they couldn't find any problem with the WAN link. Now I'm wondering will there be any settings in the Unix servers which causes this problem or is there anyway to make the telnet/ssh session active for a longer time. The netconfig settings of one of the server is given below. These settings hasn't done by me but I can modify if any change is required. Please let me know what are all the other parameters I need to check with respect to this issue.

> cat netconfig
#!/sbin/sh
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/tcp tcp_strong_iss 2
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip6_forward_src_routed 0
ndd -set /dev/tcp tcp_rev_src_routes 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/tcp tcp_conn_req_max_q0 4096
ndd -set /dev/tcp tcp_ip_abort_cinterval 60000
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
ndd -set /dev/arp arp_cleanup_interval 60000
ndd -set /dev/ip ip_ire_arp_interval 60000
ndd -set /dev/ip ip_ignore_redirect 1
ndd -set /dev/ip ip6_ignore_redirect 1
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip6_forwarding 0
ndd -set /dev/ip ip_strict_dst_multihoming 1
ndd -set /dev/ip ip6_strict_dst_multihoming 1
ndd -set /dev/ip ip_send_redirects 0
ndd -set /dev/ip ip6_send_redirects 0

> uname -a
SunOS corpldap2 5.9 Generic_112233-04 sun4u sparc SUNW,Ultra-250

Note: We can't do patch updation as it will affect some of the applications like Ingress.


Thanks,
Ashok


0
rdashokraj
Asked:
rdashokraj
  • 8
  • 3
  • 2
  • +1
3 Solutions
 
jhartzenCommented:
In my experience, this is probably a new firewall in the network which drops the session when it has been idle for too long. You could also check your shell TMOUT or TIMEOUT variables.

To test this, login remotely, and type "vi /tmp/dymmyfile", then leave the vi open and the session un-attended for 30 minutes.  If it is hanging after this time, you have a network problem.  If the session is still active, then the shell is timing out.

I hope this helps you on your way to finding the cause of the problem!
0
 
rdashokrajAuthor Commented:
Jhartzen,

As per your suggestion, I tested it by kept opening a file for more than 30 minutes, it DOESN'T hang. The session was still active. Now what to do? I checked the shell variable TMOUT and TIMEOUT but shows NULL value.

# echo $TMOUT

# echo $TIMEOUT

#

Thanks,
Ashok
0
 
PsiCopCommented:
If you're using OpenSSH, I'd suggest using ServerAliveInterval in the ssh_config file to instruct the SSH client to periodically send a keep-alive packet to the server.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
rdashokrajAuthor Commented:
PsiCop,  Is there any option available to make Telnet session to send keep-alive packets so as to keep the session active ?   Because many of our users are connecting through Telnet only.
0
 
rdashokrajAuthor Commented:
As per Jhartzen suggestion, I did VI testing in one other server. i.e opened a dummy file using VI editor and kept it idle for  about 45 minutes. Now the session got HUNGED. As per Jhartzen conclusion, if the VI session gets hunged, its a NETWORK ISSUE. Now how can I ensure that its NOT a system problem?  We maynot find the actual cause of this problem but atleast we want to know where the problem lies ?  IN SYSTEM OR NETWORK.

Please advice. Thanks.

0
 
PsiCopCommented:
Using both telnet and SSH is like having a steel-framed security door on the front of your house, and having a flimsy hollow-core door with exposed lock and hinges on the rear entrance. It's almost 2007 - unless you're in a closed network environment (and it doesn't sound like you are) you shouldn't be allowing raw telnet in to your servers anyway.

No, offhand, I'm not aware of any telnet clients that offer that level of configurability. Have them use SSH and close down telnet access.
0
 
rdashokrajAuthor Commented:
PsiCop, I agree to you. This is there in my mind always. Let me try my best to bring out a policy to make all the users to use only SSH session and close all the telnet ports in the live servers.  Btw I'm leaving for the day now and I hope that I will get a solution by tomorrow. Have a nice day. Thanks. Bye.
0
 
jhartzenCommented:
Hi again rdashokraj,
I agree, as per PsiCop, your next step is to test using an SSH client with a keep-alive option set.  The Windows version of PuTTY supports this option, it is called "TCP KeepAlive" and can be found in the options section called "Connection". This option will cause some network activity (but no shell activity) to prevent the session from expiring on firewalls/gateways en-route to the server.  Even if you can't get a telnet solution, this will still re-enforce the suspicion that it is a network related issue.

Just to be double-sure, open a vi session (to prevent the shell from causing a timeout) and enable TCP keepalive packets, then leave it open and see what happens.  You could even open up two sessions simultaneously with different settings in order to compare the results.

Good Luck
  _j
0
 
TintinCommented:
The problem you have will be with timeouts.  There are 3 possibilities:

1.  Get your ISP to change their firewall/router settings.
2.  Use keepalives from your ssh/telnet client
3.  Set TCP keepalives on the Solaris side.
 
0
 
rdashokrajAuthor Commented:

Thanks for all your advice and suggestions. We are still working with ISP to resolve this issue. Now we have changed our QOS (Quality of Service) in the firewall in such a way to give high priority to the Telnet and SSH traffic and asked the users to check. We are waiting for their result now.
0
 
jhartzenCommented:
I doubt that QOS settings will affect TCP session timeout, but let us know the outcome.
0
 
rdashokrajAuthor Commented:
We will come to know the result by monday. Thanks.
0
 
rdashokrajAuthor Commented:
Even after 3 days working with ISP, the users are still facing the Telnet Termination problem. The issue is that we couldn't conclude at what time the connection terminates. Its happens after 30 minutes, sometimes after 1 hour and sometimes after 2 hour. FYI: The users are using the "Reflection" as the client software.
Making all the users to switch over to SSH or other client software is an option but its not an easy task to implement. Bcoz there are around 2000 users and are non-technical. Not sure how to resolve this ???
0
 
rdashokrajAuthor Commented:
Changing QOS doesn't fix the problem.  Atlast we resolved it by switching over all the Reflection clients (around 2000) to use SSH connection instead of Telnet and made necessary settings in the ssh_config file of all the servers they connect. We prepared a memo on SSH connection and distributed to all the users. It may take sometime for them to get used to this SSH settings. Now things looks to be fine. No connection termination reported till now. Anyways, this helped us to make our users to switch over to SSH connection and say 'goodbye' to Telnet which they are using for ages.

Btw thanks for all your suggestions and ideas.
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 8
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now