The two overload actions are implemented as follows.
When the system is critically overloaded, new incoming traffic is ‘bypassed’, that is, simply forwarded at layer 2. No caching or policy enforcement will occur, but user traffic is not affected. For most ISP deployments, this is a desirable failsafe for appliance overload. This approach maintains transparency of the deployment.
When the appliance recovers, new connections will again be handled normally, but bypassed connections will remain bypassed until those TCP flows complete.
Bypass mode ensures minimal consequences for end-user traffic. Generally there should be no increase in perceived latency for bypassed connections.
When the system is critically overloaded, the appliance drops connection initialization packets (TCP SYNs) for incoming new connections. Clients may eventually retry their connection request, at which point the appliance may have recovered. If the system has not recovered, the client requests will eventually timeout. In this scenario, overload will generally result in increased latency or outright interruption for end-users, but avoids the possibility that URL filtering or other regulatory policy might be bypassed. That is to say, the “drop” action is the only one that guarantees URL filtering. By selecting “drop”, the appliance will either filter all proxied traffic (when healthy) or drop all incoming traffic (when unhealthy).
In both cases, HTTP connections that were already in an established state when overload was entered will continue to be handled normally, though there may be increased latency if the appliance is severely resource constrained. That is, no established connections are subject to the ‘drop’, only new connections.
If the deployment is subject to URL filtering or other mandatory regulatory filtering, then “drop” should be used. In these cases, “bypass” would allow traffic through without the required filtering.
In all other cases, “bypass” is strongly recommended. Bypass mode is designed as ‘graceful’ mechanism for overload, with minimal subscriber interruption. For this reason, it is the recommended setting for all applicable deployments.
In CacheFlow OS version 2.x, to enable the Overload Bypass recommended configuration use the following commands:
#(config general)resource-overflow-action bypass
To enable drop on overload (for URL filtering)
#(config general)resource-overflow-action drop