ICMP Test

Use this test to monitor the ICMP traffic on the NetScaler and to understand how well the NetScaler handles the traffic. The metrics reported by this test promptly capture ICMP rate threshold violations and thus reveal a potential ICMP overload on the NetScaler appliance. In addition, the test sends out instant alerts to administrators when ICMP-related errors are detected.

Target of the test : A NetScaler VPX/MPX

Agent deploying the test : A remote agent

Outputs of the test : One set of results for the NetScaler appliance being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The IP address of the host for which the test is being configured.

NetScaler Username and NetScaler Password

To monitor a NetScaler device, the eG agent should be configured with the credentials of a user with read-only privileges to the target NetScaler device. Specify the credentials of such a user in the NetScaler Username and NetScaler Password text boxes.

SSL

The eG agent collects performance metrics by invoking NITRO (NetScaler Interface Through Restful interfaces and Objects) APIs on the target NetScaler device. Typically, the NITRO APIs can be invoked through the HTTP or the HTTPS mode. By default, the eG agent invokes the NITRO APIs using the HTTPS mode. This is why, the SSL flag is set to Yes by default. If the target NetScaler device is not SSL-enabled, then the NITRO APIs can be accessed through the HTTP mode only. In this case, set the SSL flag to No.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

ICMP rate threshold

Indicates the limit of ICMP packets handled every 10 milliseconds.

Pkts/Sec

This threshold is configurable. Once this threshold is violated, subsequent ICMP packets will be dropped by the appliance. You are hence advised to configure this limit based on the current and anticipated ICMP traffic to the NetScaler appliance. To view the configured threshold, use the show ns rateControl command. To set/alter this limit, use the set rateControl command.

ICMP data received

Indicates the amount of ICMP data received during the last measurement period.

MB

These measures are good indicators of the ICMP load on the NetScaler appliance.

ICMP data transmitted

Indicates the amount of ICMP data transmitted during the last measurement period.

MB

ICMP packets received

Indicates the number of ICMP packets received during the last measurement period.

Number

ICMP packets transmitted

Indicates the number of ICMP packets transmitted during the last measurement period.

Number

ICMP echo received

Indicates the number of ICMP “Echo Request” and “Echo Reply” packets received during the last measurement period.

Number

The echo request is an ICMP message whose data is expected to be received back in an echo reply ("ping"). The host must respond to all echo requests with an echo reply containing the exact data received in the request message.

 

ICMP echo replies received:

Indicates the number of ICMP echo replies received during the last measurement period.

Number

ICMP echo replies transmitted

Indicates the number of ICMP echo replies transmitted during the last measurement period.

Number

ICMP port unreachable received

Indicates the number of times the “ICMP Port Unreachable” error message was received during the last measurement period.

Number

The ICMP Port Unreachable error is generated when there is no service running on the port.

Ideally, the value of these measures should be 0.

ICMP port unreachable transmitted

Indicates the number of times the “ICMP Port Unreachable” error message was received during the last measurement period.

 

 

Need fragmentation received

Indicates the number of times the “ICMP Fragmentation Needed” error message was received for the ICMP packets during the last measurement period.

Number

This measure tracks the ICMP Fragmentation Needed error messages received for packets that must be fragmented but Don't Fragment is specified in the header.

ICMP rate threshold exceeded

Indicates the number of times the value reported by the ICMP rate threshold measure has been violated.

Number

A high value of this measure indicates that the ICMP rate threshold has been violated often. When this happens, you must first ensure that the ICMP packets received are genuine. If they are genuine, then you must increase the current rate threshold.

Note that if the rate threshold is violated, then the appliance will drop subsequent ICMP packets it receives. To assess the impact of the threshold violation, use the ICMP packets dropped measure. If the value of this measure is very high, its a clear call for a change in the rate threshold. 

To view the configured threshold, use the show ns rateControl command. To set/alter this limit, use the set rateControl command.

ICMP packets dropped

Indicates the number of ICMP packets that were dropped during the last measurement period because the rate threshold was violated.

Number

A high value is a cause for concern, and presents a strong case for changing the rate threshold.

Bad ICMP checksum

Indicates the number of ICMP Fragmentation Needed error messages received with an ICMP checksum error in the last measurement period.

Number

Ideally, the value of this measure should be zero.

PMTU non-first IP fragments

Indicates the number of “ICMP Fragmentation Needed” error messages received for an IP fragment other than the first one upon Path MTU Discovery during the last measurement period.

Number

NetScalers have a feature called Path MTU Discovery, which is actually a common feature on most networking devices. Path MTU Discovery allows a networking device such as the NetScaler, or routers and switches, to determine the largest packet size allowed along an arbitrary network path. This enables network traffic to flow correctly from one endpoint to another, without any of the traffic being dropped.

The IP protocol has a mechanism for signaling that datagrams are too large to pass through an interface on a network path – when a datagram is received on a router or Layer 3 switch interface that is larger than the interface’s MTU, the device sends an Internet Control Message Protocol (ICMP) message to the previous hop device indicating that the datagram needs to be fragmented in order to pass through that interface, as well as the MTU of the interface. The previous hop device breaks the datagram into pieces that are small enough to pass the next hop interface’s MTU.

While this mechanism is usually sufficient to allow traffic to continue normally, it does have some drawbacks. The increase in the number of datagrams from fragmenting means Layer 3 routing has that much more work to do in routing decisions. There is always the possibility that another device further along the network path has an interface with an even smaller MTU and requires further fragmentation, and when the destination device for these datagrams eventually receives them, all datagram fragments must be received so it can be reassembled correctly. If all fragments are not received, the entire original datagram is dropped and must be retransmitted by the sending station (and will probably be fragmented in transit again). This is why, the value of this measure should be kept at a minimum.

 

PMTU invalid body length received

Indicates the number of “ICMP Fragmentation Needed” error messages received for invalid body length of the packets determined by the Path MTU Discovery during the last measurement period.

Number

 

PMTU no TCP connections

Indicates the number of “ICMP Fragmentation Needed” error messages received for TCP packets during the last measurement period.

Number

The state of the connection for these packets is not maintained on the NetScaler appliance.

PMTU no UDP connections

Indicates the number of “ICMP Fragmentation Needed” error messages received for UDP packets during the last measurement period.

Number

The state of the connection for these packets is not maintained on the NetScaler appliance.

PMTU invalid TCP sequence number received

Indicates the number of “ICMP Fragmentation Needed” error messages received for the packets containing an invalid TCP address determined by the Path MTU Discovery during the last measurement period.

Number

 

Invalid next MTU value received

Indicates the number of “ICMP Fragmentation Needed” error messages received for the packets in which the Maximum Transmission Unit (MTU) for the next hop was out of range during the last measurement period.

Number

The range for the MTU is 576-1500.

Next MTU greater than current MTU

Indicates the number of “ICMP Fragmentation Needed” error messages received in which the value for the next MTU was higher than the current MTU during the last measurement period.

Number

 

PMTU invalid protocol received

Indicates the number of “ICMP Fragmentation Needed” error messages received for the packets containing protocols other than the TCP and UDP protocols during the last measurement period.

Number

 

PMTU IP check sum error

Indicates the number of “ICMP Fragmentation Needed” error messages received for the packets containing IP checksum errors during the last measurement period.

Number

 

PMTU PCB with no link

Indicates the number of “ICMP Fragmentation Needed” error messages received on a Protocol Control Block (PCB) with no link during the last measurement period.

 

Number

The PCB maintains the state of the connection.

PMTU discovery not enabled

Indicates the number of “ICMP Fragmentation Needed” error messages received when the Path MTU Discovery was not enabled during the last measurement period.

Number