The moment I understood that networking is layered, I had an epiphany about how everything on our computers is layered, including programs, which are fragmented into API layers, and state machines on top of network protocols. The combinations are sometimes mind numbing. But for networking, somebody tried to decode it. Like models in physics, the Open Systems Interconnection (OSI) model was introduced in an attempt to define the properties of network layers. As it turns out, the layers are nuanced but in any case, there are network layers!
As Message Analyzer parses things more completely, it makes some sense to focus on the tops layers in some cases, especially when users need understand a problem from their perspective. We also automatically reassemble payloads, which hides the details under a Virtual TCP Segment. This helps the default display become very compact, which tells you the story at a high level only.
But, alas, sometimes you must put on your nautical network suit and dive into the deeper layers. Wouldn’t it be cool to perform a “layer“ filter (similar but different from our filters today), that would let you see a layer based on a protocol’s viewpoint. Let’s submerge.
- Application/Presentation/Session Layer – we’ll start our decent into the OSI Ocean at the top. The layers up here tend to float up to the top most. In some cases, you are viewing the layers of various APIs (over RPC) or HTTP communications. An SMB conversation might appear and then change into RPC, which can be hosted on top. So the view here is often fragmented anyways. So perhaps we could and should have HTTP, SMB, and RPC viewpoint filters. By the way, another feature that affects all layers, is that you can add ETW sources and text log files as sources as well. In this case, HTTP/SMB/RPC providers are often instrumented with logging which can be combined and correlated to each other.
- Transport Layer – of course we’ll focus on the TCP/UDP part of the ocean for our dive. This is a very common layer to troubleshoot, for example, retransmits and performance are common issues here. We can add provider data for sockets and other things as well.
- Network Layer – could be limited to IPv4, IPv6, DHCP, and other TCP/UDP related protocols. Of course there are other Network Layers, but you could start by picking an initial area of focus. And again, the TCP provider could let us correlate to the system state.
- Data Link Layer – we arrive at the abyss, the sea floor of our analogy which includes Ethernet, ARP, LLC, and possibly other protocols.
- Physical – now we are in the ocean trenches, which often aren’t exposed to us through tracing. That could mean wireless Meta data, like signal strength and data rate. Of course, any data you can import into Message Analyzer (text files, traces, ETW) can be added to any viewpoint.
Defining a Viewpoint
For now, we’ll have to help configure these. We plan to expose a UI, but this will come later. But we should be able use the community to help expand these (more on Community and Sharing in another blog). But in box, we did some very simple things to focus on TCP both before and after reassembly. We do SMB/SMB2 together to remove RPC and other protocols on top. IPv4 and IPv6 could be looked at separately, but I think these could be combined. UDP is also alone, but maybe this should be merged into TCP.
Using the feature means interacting with the Viewpoints section of the ribbon.
By default, Message Analyzer is at the “Default Viewpoint” which means you see any protocol/layer that has no other layer on top of it.
In this example, I select the TCP Viewpoint. This sets the viewpoint to see TCP related traffic. Payloads above are not shown. But you can still see all the layers by displaying the new Call Stack tool window.
Here’s my TCP view after applying the TCP Viewpoint. Note how the full stack shows in the Call Stack tool window in the figure below. You can see that this message parsed as HTTP. Keep in mind that many messages could be part of the same top-level. Also, note that the Call Stack drives the Details tool window. This lets you explore the upper layers if you want.
Today, a display filter only applies to the viewpoint layer. If you try to filter on HTTP when you are at the TCP viewpoint, you’ll see no matching messages. But we plan to give you the option to choose how that works. It certainly seems useful to look at a layer, based on a higher layer filter.
Turning Operations On
In Message Analyzer, operations collapse traffic to combine related request/response pairs into a single, top-level message line. However, we always knew that you need to understand the interaction between requests and responses. So now, you can independently toggle operations to alternately hide and show them. Below is some traffic with operations turned on, which is the default setting.
With operations hidden, the HTTP get and response is split into two separate messages, as shown in the figure below. In fact, you can see that the two HTTP requests occurred sequentially. With operations turned on, we lose this information as it appears we did a request, got a response, and then again. But that’s not the whole story. So often you need to remove operations to understand how each request and response of operation intermingles.
Let’s Build Some Viewpoints Together
With community support, we’ll be able to share all sorts of cool things. For now, with Beta3, my team will have to help push out Viewpoints, but as I mentioned before this is changing. We’d love to hear your comments and suggestions and have fun on your dive!
To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet: