Using nstrace to capture a packet trace

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.

Steps to run a trace

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 0 unless 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.
    Steps to run a trace

    Note

    Versions 11.0 and later offer the ability to directly capture decrypted SSL Packets. To do this select the Decrypted SSL packets (SSLPLAIN) option

  • Leave the capture trace in the .pcap format 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 the NetScaler Packet Trace header:
    Steps to run a trace

Here are some of the most helpful NetScaler packet trace fields:

  • The Operation field that shows whether the packet is transmitted or received.
  • The Nic No field shows you the interface on which the packet was received. For example, the trace shows 0 and show interface shows Interface 1/1 (NetScaler Virtual Interface) #0, hence we know this packet was transmitted on 1/1.
  • The VLAN ID field.
  • PcbDevNo and Linked PcbDevNos will help you identify the frontend and backend legs of a conversation. For example, nstrace.pdevno == 0x000696d5 || nstrace.l_pdevno == 0x000696d9 based 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.78.64