Which NetScaler tool would you use to troubleshoot resets on an intranet server load-balanced by NetScaler?

• A. Look in the Event Viewer
• B. nslog via CLI
• C. Take a packet trace with nstrace and analyze with WireShark
• D. nslog

Answer: (C)

To diagnose TCP resets, you need visibility at the packet level to see exactly who is sending the reset and why. Taking a packet trace with nstrace on the NetScaler captures the traffic between the client, the appliance, and the backend servers, including the RST packets and the surrounding TCP state. Analyzing that trace in WireShark lets you inspect TCP flags, sequence numbers, and the handshake state, so you can determine whether the reset comes from the client, NetScaler, or a backend server, and reveal the cause (timeout, invalid state, server closing, MTU issues, etc.).

Other options don’t provide that direct packet-level insight: Event Viewer shows Windows events, not the actual TCP reset flow; NetScaler logs (nslog) record events but not the full packet detail needed to pinpoint the reset cause. Thus, combining nstrace with WireShark analysis is the most effective way to troubleshoot resets.