| Measurement |
Description |
Measurement
Unit |
Interpretation |
| New_client_connections |
The number of new client connections to the Netscaler device in the last measurement period |
Number |
|
| New_server_connections |
The number of new connections established between servers and the
Netscaler device in the last measurement period |
Number |
|
| Tcp_offload_factor |
This factor monitors the connections from the Netscaler device
to servers as a factor of the connections it receives from clients. |
Percent |
One of the key benefits of the Netscaler device is its ability to offload TCP
connection processing from the servers to the Netscale device itself. By doing
so, the Netscaler device allows the existing server infrastructure to support
a larger workload. The lower the value of this metric, the greater the benefits
of the Netscaler device. |
| Current_client_conns |
The number of connections currently established by clients to the Netscaler device |
Number |
|
| Current_server_conns |
The number of connections currently established by the Netscaler device to servers |
Number |
|
| Client_conns_refused |
The number of connections from clients that were refused by the Netscaler device during the last measurement period. |
Number |
This value should be close to 0 for ideal operation. |
| Cookie_seq_rejects |
This metric represents the number of connections rejected because
of syn cookie sequence number mismatch. |
Number |
Normal SYN cookies contain encoded information that makes
it near impossible to request a connection to a host from a forged (spoofed) originating address. In this scenario, the
attacker must guess a valid TCP sequence number used by that server to connect to some other legitimate host. The
cryptographic protection in the standard SYN cookie makes this attack possible with as few as one million guesses, which
is not impossible for a determined attacker. NetScaler uses an enhanced SYN cookie protection scheme that is fully compatible with the TCP/IP protocol, but have rendered the “forged connection” technique obsolete. Each new connection is unrelated to previous connections, and knowing a valid sequence number used for a previous connection will not enable an attacker to forge a connection.
A large value of this measure could indicate failed attempts made to hack into a network. Further investigation is hence, necessary.
|
| Cookie_signature_rejects |
This metric represents the number of connections rejected because of syn cookie signature mismatch. |
Number |
|
| Unack_syns |
This metric represents the number of connections dropped because of unacknowledged
SYN packets. |
Number |
When a client attempts to establish a TCP connection to a server, the client
and server exchange a set sequence of messages. This connection technique
applies to all TCP connections (for example, Telnet, web, E-mail, and so on).
The sequence for the TCP connections are:
- The client sends a SYN message to the server.
- The server acknowledges the SYN message by sending a SYN-ACK message
to the client.
- The client finishes establishing the connection by responding to the server
with an ACK message
When the sequence is complete, the connection between the client and server
is open, and service-specific data can be exchanged between the client and
server. The potential for attack arises at the point when the back-end server has sent
an acknowledgement (SYN-ACK) to the client but has not received the ACK
message from the client; this is referred to as a half-open connection in the server.
A high value of this measure indicates that too many such half-open connections exist in the server, which could consume excessive system memory, causing the server system to crash or hang, or deny service to legitimate clients. |
| Current_servers |
This metric represents the number of connections established with servers. |
Number |
|
| Server_conn_hits |
The number of client transactions in the last measurement period that
used the server connection in the reuse pool |
Number |
Netscaler appliances support a 'Connection Keep-Alive' feature that is enabled for HTTP protocols, so that persistent connections are available between the system and the client over the WAN link and also between the system and the server. This is achieved by mimicking HTTP “connection-persistence” behavior to both the client and server. The server always perceives that it is communicating with a persistent client (even if the client is not persistent) and the client always thinks it is communicating with a persistent server (even if the server is configured not to do keep-alive; for example, the server is configured to do one request per connection). One of the key benefits of this feature to a server is the creation and maintenance of a pool of ready-to-go fast server connections (i.e., the reuse pool). This pool ensures that connection requests from clients are serviced by the pool itself without having to open actual connections on the server, and thus greatly reduces the connection-burden on the server.
If the value of the Server_conn_hits measure is very low or the Server_conn_misses measure is very high, it indicates that the pool is not been effectively utilized. A very low Server_conn_hit_ratio is also indicative of the same. If such a situation persists, it can only result in more physical connections been opened on the server, and consequently, excessive CPU and memory erosion at the server-level. You can counter this abnormal event by ensuring that the Connection Keep-Alive feature is always enabled.
|
| Server_conn_misses |
The number of new connections made during the last measurement period
because the server connection was unavailable in reuse pool |
Number |
| Server_conn_hit_ratio |
This metric is a measure of the efficiency of the server reuse pool. |
Percent |
| Cpu_usage |
The current CPU usage of the Netscaler device |
Percent |
Ideally, this value should be low. |