Selecting a Resource Overload Action for my CacheFlow 5000 appliance

Solution

Overview

The CacheFlow 5000 appliance is considered "overloaded" when it cannot keep up with the incoming request load. Rather than fault or block transactions, it applies a "resource overload action" to handle the over-capacity load. This action is either "bypass" or "drop", and is configurable to suit the deployment in question.

What Resource Overload Action should be selected for my deployment: Bypass or Drop?

Cause
Resolution

The two overload actions are implemented as follows.

Bypass

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.

 

Drop

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.

 

Recommendations

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
#(config general)resource-overflow-action bypass

To enable drop on overload (for URL filtering)

#(config)general
#(config general)resource-overflow-action drop 

Workaround
Additional Information
Bug Number
InQuira Doc IdKB4362
Attachment

Article Feedback

Did this Article solve your issue?
Additional Comments:
 
Previous MonthNext Month
SunMonTueWedThuFriSat