Follow the Stream
This is not some existential trip or search for life's meaning. Rather this refers to a feature protocol analyzers use to narrow down traffic in a network trace. I mentioned this briefly in my Cable Talk Blog back on November 15th, 2006. In fact you should refresh your memory as we'll refer to topics discussed in that article.
To follow a stream in a general sense means to narrow down the network traffic to a specific conversation. This could mean between two machines, between two specific TCP ports, or even two applications. You can also see how these conversations could be hierarchical; where a conversation between two machines could be further broken into conversations between specific TCP ports.
What's so good about that?
Why is this useful, you may ask? Given that a network trace could have thousands of connections occurring, you'll need a way to find that needle in the haystack. Also, you may be looking at a problem frame and want to look at the rest of the related traffic. Being able to quickly narrow down the packets for related network traffic can help speed up your analysis time on complex traces.
Turn On Conversations
By default we have disabled conversation tracking to save memory and provide better performance out of the box. But in order to benefit more fully from this protocol analyzer, conversations should be enabled before you start a new capture or open a preexisting capture.
Cat Skinning: Method 1
Using the conversation tree is one way to skim through the various conversations that NM3 has exposed. Remember that the parsers define what a conversation is to NM3 and the conversation tree is simply a visual representation of this conversation data. By clicking on a node in the tree, you see the trace summary information reflect only those frames associated with this conversation as well as every conversation built below it.
This is a really nice way to step through each conversation and get an overview of what's happening. In fact, by opening the tree for an IPv4 level conversation with sub-conversations, you can tell how many connections a server has and get some idea of the types of things that are happening on this machine. This is a fast way to differentiate a busy machine from an idle one. A virus that scans ports would be evident because it would create a series of TCP conversations.
Cat Skinning: Method 2
Often, you'll already have a frame in focus and now you'd like to see the rest of the conversation for this frame. Now as hinted to before there may be multiple streams which include this same frame. So you must first decide what context you want to relate the data in.
In NM3, all possible streams are described by the Conv Id Column. This lists each conversation with the protocol and a number which defines the unique number assigned for that conversation. NM3 simply increments a counter for each new conversation, but you can't guarantee the numbers will be the same on two different machines if the parsers are different. Here's an example of that column:
{HTTP:81, TCP:80, ESP:78, IPv4:77}
So using this information you can create a filter to view any of the conversations that this frame is listed a part of. For TCP, a filter of "Conversation.TCP.ID==80" will return all frames that have the same port pair and IP address pairs as this particular frame. What makes this really flexible is that you can show two streams at the same time by combining two separate conversation filters. You might find this helpful when looking at a trace where the server acts as an intermediary (like a proxy server or front end for a SQL DB or Exchange Server). So for instance the following filter will show both TCP conversations 80 and 81.
Conversation.TCP.ID==80 OR Conversation.TCP.ID==81
One missing feature is the ability to track back to the conversation tree from the currently selected frame. While making it a click away would be more ideal, you can make some NPL changes as mentioned in the Cable Talk Blog.
So where's the Data?
While looking at your specific TCP stream, you may want to see the payload data to give you even a better idea of what is going on. For protocols we don't have parsers for, you could use the information in my "Using Columns and Properties" blog:
(https://blogs.technet.com/netmon/archive/2007/03/01/using-columns-and-properties.aspx)
We mention in this article that you can add the TCPPayload column. This payload data described as Text may help to discover what is going on. For other streams, you could use the techniques in the previously mentioned blog to create your own property to display info you need to see. More than likely, however, for any public parsers the summary information should be of great help already.
When you're lost in the jungle…
They often tell you to follow a stream as this will lead you to civilization. Somehow the analogy seems to have similar results in that you can derive some order from the chaos by following a conversation stream. Once you become more accustomed to look at data in this light, you can tame the most unruly of network traces.