While the logs on the NetScaler help build a picture of what happened, it is oftentimes necessary to delve deeper and identify what device is responsible for the issue (for example, is it the Server, NetScaler, or the Network?). Examining a network trace taken on the NetScaler helps identify the next steps by narrowing down the focus area.
You can take a trace using the GUI, the CLI, or the shell. The recommended way is to do this over the GUI, which provides easy dropdown-based filtering choices as well as an option to download the trace once it's captured.
To take a trace from the GUI, use the start new trace option in the Diagnostics section.
Let's take a look at some general recommendations for running a trace.
- Always attempt to capture simultaneous traces to start with—on the client machine, NetScaler and server.
- Run the trace with a packet size of
0unless the packets you are looking for are really small, especially SSL traces. The certificate that needs to be captured will be larger than the 164 bytes and that would mean the trace is not decryptable.
- Leave the capture trace in the
.pcapformat unchecked. This will capture the trace in the proprietary NetScaler format—a format that captures a wealth of NetScaler-specific info that you can see by opening up theNetScaler Packet Traceheader:
Here are some of the most helpful NetScaler packet trace fields:
- The
Operationfield that shows whether the packet is transmitted or received. - The
Nic Nofield shows you the interface on which the packet was received. For example, the trace shows0and show interface showsInterface 1/1 (NetScaler Virtual Interface) #0, hence we know this packet was transmitted on1/1. - The
VLAN IDfield. PcbDevNoandLinked PcbDevNoswill help you identify the frontend and backend legs of a conversation. For example,nstrace.pdevno == 0x000696d5 || nstrace.l_pdevno == 0x000696d9based on the preceding screenshot will give you both legs of the conversation.
If you exactly know the packet you are looking for and are running a huge amount of traffic, you can rely on the filtering capabilities provided in the GUI. This is a great way to capture smaller traces. However, where possible, my recommendation when you first start troubleshooting a problem is to take unfiltered traces so you can see the full picture, for example, you are looking for why HTTP is failing but the problem is originating due to ARP or DNS failures.
So, start by capturing a short trace of all packets and work your way up to more specific traces.