TCP profiles have been really helpful and handy to use for various use cases and deployment scenarios. Couple weeks back we had discussed TCP profiles and the last blog (/blogs/2012/04/26/netscaler-10-tune-tcp-stack-for-wireless-use-cases-with-westwood/) covered the Westwood enhancement for Wireless networks. Latest NetScaler 10 GA build adds new Keep-Alive feature on TCP stack and enables NetScaler to probe the TCP connections from NetScaler end. Following snapshot shows the various options available with Keep-Alive feature.

In today’s use cases Keep-Alive can be of good help because it enables NetScaler to proactively find out if the client is alive or dead while it consumes connection resources. After a preconfigured time, NetScaler sends Keep-Alive probe packets to the client and waits for the acknowledgement. In case the packet gets dropped or the client does not respond back in time, NetScaler can send repeated probes per the configuration. Finally NetScaler can decide to reset the connection if after repeated probes client does not respond back at all. This way NetScaler can free up the resources and use them for other active clients. This is also true for the server side TCP communication because the same profile can be bound to services as well. Let us go over the settings:

  • Keep-alive probes
    • By default it is kept disabled
    • By enabling it rest of the parameters would come into action
  • Connection idle time before sending probes
    • This is the time we wait on an idle connection before sending probes
    • By default we wait for 15 minutes (900 sec) and you can change it as you want
  • Keep-alive probe interval
    • After 15 minutes of idle time we send the first probe out
    • What if the client does not respond to the probe or it gets lost on wire
    • We cannot terminate the connection just based on single probe
    • This setting enables us to send successive probes after given interval
  • Maximum keep-alive probes
    • This works along with the previous setting
    • The number of probes define how many successive probes we need to send
    • Every probe is sent after the defined interval with previous setting
    • If the client responds back after first probe then rest of them are not sent
    • On receiving client’s response we go back to 15 minutes idle time logic

You need to be careful of the Keep-Alive probe interaction with Idle timeout setting on respective vserver or services. In case of lower idle timeout, the connection will be flushed before the Keep-Alive logic ever triggers on the flow. I am sure given the resource crunch we go through on daily basis, this new feature is going to help most of the common deployments…