About auto kickoff and client connection reset
Auto kickoff resets existing connections, forcing client systems to go through the connection creation process with the appliance again. While this feature is enabled, restarting the service resets existing connections. After the connections are reestablished, traffic is accelerated.
Generally, connections are short-lived and kickoff is not necessary. It is suitable for certain long-lived connections, such as data replication, and very challenging remote environments. For example, you would want connections in a remote branch-office with a T1 link and a 35-ms round-trip time to accelerate gracefully, rather than risk interruption with kickoff.
Do not enable kickoff for in-path appliances that use autodiscover, or if there isn’t an appliance on the remote side of the network. An appliance’s default behavior is to autodiscover all connections.
You can enable kickoff:
• globally for all existing client connections under Optimization > Network Services: General Service Settings.
• for all existing connections that match an in-path rule with kickoff enabled.
• for a single pass-through or accelerated connection in the Current Connections report, one connection at a time.
When enabled and the service is restarted, the appliance sends RST packets to connected clients and servers to try to close the connections. Next, it sets an internal flag to prevent any further kickoffs until the service is once again restarted. If no data is being transferred between the client and server, the connection is not reset immediately. It resets the next time the client or server tries to send a message. Therefore, when the application is idle, it might take a while for the connection to reset.
In most deployments, you don’t want to set automatic kickoff globally because it disrupts all existing connections. Instead, consider using in-path rules to reset connections to and from specific subnets, IP addresses, or ports. In-path rule kickoff overrides the global kickoff setting for matching connections.
For in-path rules, the appliance applies the first rule to match. It doesn’t consider VLAN tag IDs. Consequently, the appliance resets matched connections on different VLANs. In-path rule matching operates by matching both the source and destination attributes of a connection. For an in-path rule where source and destination IP and subnet are set to 192.0.2.0/24 and 192.0.3.0/24 respectively, and kick off is enabled, connections between 192.0.2.0/24 to 192.0.3.0/24 are bidirectionally reset when you restart the service.