Working with Clusters and Match Rules
Once Only Option and HTTP / HTTPS Timeouts
The previous sections describe how the connection timeouts work when the once only flag is
disabled on a cluster; that is, when Equalizer is examining every set of headers received on a
connection. The once only option, when enabled, specifies that Equalizer will examine only the
first set of headers received on a connection. This has the following effects on connection
timeouts:
l
If you have once only enabled, as soon as the initial transaction (client request and server
response) on a connection completes, the connection goes into “streaming” mode and the cli-
ent timeout is no longer used for this connection. Equalizer does not parse any additional cli-
ent requests received on the connection. The server timeout is used for the remainder of
the connection, and is reset whenever data is received from either side of the connection.
l
If you have once only disabled as described in the previous sections, and multiple requests
are being sent on the same connection, the client timeout starts counting down again as
soon as a new request is received from the client.
Layer 4 Connection Timeouts
Connections to Layer 4 clusters are received by Equalizer and forwarded with little processing.
Equalizer simply rewrites the source and/or the destination IP addresses, as appropriate for the
cluster, and sends the packet to the server specified by the cluster’s load balancing policy. For
Layer 4 TCP clusters, a connection record is kept for each connection so that address translation
can be done on the packets going between the servers and clients. The Layer 4 connection
timeouts specify how long a connection record is kept by Equalizer.
Layer 4 TCP clusters use the idle timeout and stale timeout parameters that set at cluster levels.
The parameters affect how Equalizer manages Layer 4 connection records:
l
Connection records need to be removed in cases where the connection is not closed by the
client or server, and is left idle. If no data has been received on a connection from either
the client or the server after the time period specified by the idle timeout has elapsed, then
Equalizer removes the connection record for that connection. Any data received from either
client or server resets the idle timer.
Note that when using Direct Server Return (DSR), the time that a connection record is main-
tained is determined by adding the idle timeout for the cluster to the sticky time . This addi-
tional time is necessary when using DSR, since no server responses are routed through
Equalizer (and therefore cannot restart the idle timeout to keep the connection open). For
more information on DSR, see
"Configuring Direct Server Return"
l
In other cases, a connection may be initiated but never established, so the connection
record goes “stale” and must be removed. If a client fails to complete the TCP connection
termination handshake sequence or sends a SYN packet but does not respond to the
server’s SYN/ACK, Equalizer marks the connection as incomplete. The stale timeout is the
length of time that a connection record for an incomplete connection is maintained.
When Equalizer reclaims a connection, it sends a TCP RST (reset) packet to the server, enabling
the server to free any resources associated with the connection. (Equalizer does not send a TCP
RST to the client when reclaiming a connection.)
324
Copyright © 2014 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Summary of Contents for Equalizer GX Series
Page 18: ......
Page 32: ...Overview 32 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Page 42: ......
Page 52: ......
Page 64: ......
Page 72: ......
Page 76: ......
Page 228: ......
Page 238: ......
Page 476: ......
Page 492: ......
Page 530: ......
Page 614: ......
Page 626: ......
Page 638: ......
Page 678: ......
Page 732: ...Using SNMP Traps 732 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Page 754: ......
Page 790: ......
Page 804: ......
Page 842: ......
Page 866: ......