About auto kickoff and client connection reset
Auto kickoff forces client systems to reestablish their connections with the appliance by resetting existing connections. This occurs when the service is restarted, and after the connections are reestablished, traffic is accelerated.
While most connections are short-lived and don't require kickoff, it is useful for long-lived connections, like data replication, or in environments with challenging conditions. For example, in a remote branch office with a slow T1 link and a high round-trip time, auto kickoff helps ensure graceful acceleration without interrupting the connection.
Auto kickoff should not be enabled for in-path appliances that use autodiscover or if there is no appliance on the remote side of the network. By default, appliances 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 close connections and prevents further kickoffs until the service is restarted again. If no data is transferred, the connection isn't immediately reset, but it will reset when the client or server attempts to send a message. So, it may take time for idle connections to reset.
Generally, it's better not to enable global kickoff, as it disrupts all existing connections. Instead, use in-path rules to reset connections for specific subnets, IP addresses, or ports. These rules override the global setting. The appliance applies the first matching rule and resets connections based on the source and destination attributes. For example, a rule that matches connections from 192.0.2.0/24 to 192.0.3.0/24 will reset those connections when the service restarts.