Diagnosing Network Issues with the New Pattern Match Viewer


Another recent improvement in Message Analyzer 1.3 is the Pattern Match viewer. We’ve updated the user interface (UI), which should enable you to get started with configuring and finding sequential patterns in your data more effectively. This article shows you how to open the Pattern Match viewer and then provides a review of the new interfaces to help you understand how to diagnose network issues by using one of the built-in Pattern Expressions as an example.

Opening the Pattern Match Viewer

Message Analyzer processes your data and displays it in a viewer of choice. Traditionally, a grid-based view with rows of messages is the typical display, such as what you have with Network Monitor or Notepad files (when viewing text log data). Among the many data viewers that Message Analyzer provides the Pattern Match viewer is unique, given that it not only displays Pattern Match data but also enables you to create and execute your own Pattern Expressions. You can access this viewer by selecting the Pattern Match item in the New Viewer drop-down list on the Message Analyzer global toolbar, as shown in the figure that follows.

Tip: You can use the search feature at the top of the New Viewer drop-down list to find viewers, which are generically defined as assets that are easily sharable.

clip_image001

In my case, I’ve set the Pattern Match viewer as a Favorite by clicking the white star next to this viewer in the list, which changes its color to yellow (clip_image003) and moves it into the Favorites category of the list for quick access.

Pattern Match UI Updates

Besides the name change from Sequence Match to Pattern Match, we list a set of built-in patterns in the AVAILABLE PATTERNS section of the UI, rather than the former method of accessing the list from a menu on the Ribbon/toolbar. Now you can immediately see the list of available patterns that are built-in to Message Analyzer as soon as you open the Pattern Match viewer. You can check one or more Pattern Expressions in the Network category to execute them, at which time the UI will start to populate with data, providing that one or more matches are found. Note that the Pattern Match UI is split into 4 panes, as shown in the figure that follows and described thereafter:

image

1. AVAILABLE PATTERNS – contains the list of the built-in patterns in addition to any you might have created, or patterns imported from a subscriber feed. To execute one or more Pattern Expressions, place a check mark in the check box of the pattern/s that you want Message Analyzer to search for in your data. Note that some Pattern Expressions are complex, which could result in taking a long time to return matches and might cause high utilization of your CPU.

2. MATCHES – when matches are found, the type of patterns returned are listed in a Matched pattern selector for each pattern definition. Each Matched pattern selector in the MATCHES pane contains a summary that describes how many matches of the pattern were found and how many messages that includes, given that a pattern match can involve many messages. The Matched pattern selector also has a graph that provides a relative indication of where the Pattern Matches occurred in time.

Additionally, a blue info icon (clip_image007) link can appear, if there is related help for the Pattern Match scenario on the web. When you click the link, more information about the matched pattern can be provided to your browser. For the TCP Three-Way Handshake example provided in this blog, the link points to a wiki page about TCP.

Note: When you configure a Pattern Expression of your own, you can specify a custom link for the blue information icon that points to a site of your choice.

3. MATCHED INSTANCE – by clicking the check box in the Matched pattern selector window (MATCHES pane), you can see all of the instances of that pattern in the MATCHES INSTANCES pane of the UI. You can also select multiple check boxes to simultaneously display the data for more than one pattern type, perhaps providing you with information on how two patterns comingle. When you select a matched instance in the MATCHES INSTANCES table grid, this action automatically displays that group of messages in the Messages pane of the Pattern Match viewer, while globally other Message Analyzer tools snap to the selection, for example, the Message Stack and Details Tool Windows. If you have the Analysis Grid viewer open, those messages will be highlighted in the grid as well for correlation with other data.

In addition, each instance has some unique information about the match. In the case of the TCP Three-Way Handshake pattern expression, the approximate round trip time (ApproxRTT) and other data is included for analysis; which we’ll dig into further later on. Also, a Timeline column in the MATCHES INSTANCES pane provides an indication of where each Pattern Match occurred relative to other matches.

4. MESSAGES – for each MATCHED INSTANCE that you select in the MATCHED INSTANCE pane, you can see the associated messages listed in the MESSAGES pane. If you select a single message in the MESSAGES pane, it is automatically selected globally as indicated earlier, which is useful if the messages are not located next to each other. Again you can select multiple MATCHED INSTANCE and observe how the messages interact.

Network Analysis with the TCP Three-Way Handshake

The goal of this particular pattern is to expose some information about the 3 way handshake. Certainly there may be cases where the handshake is missing, but for those that are detected, I can show some useful information. By looking at the columns in the MATCHED INSTANCE pane, you will see field data of a type that is similar to what is shown in the following figure:

Tip: You can hide (image) the AVAILABLE PATTERNS pane to free up more horizontal real-estate.

image

image

Fields for Every Pattern – every MATCHED INSTANCE of a Pattern Expression has a set of standard fields that are organized as columns in the MATCHED INSTANCE pane, as defined below:

  • Pattern – the name of the Pattern Expression that was matched.
  • Instance – the instance of the match, starting at zero.
  • Start – the Timestamp of the first message in the pattern.
  • End – the Timestamp of the last message in the pattern
  • Elapsed – indicates how long from the first to last message in the Pattern Expression.
  • Messages – the number of messages that make up this instance of the Pattern Expression. For the TCP Three-Way Handshake pattern, this number is always 3, but even the same Pattern Expression could have different number of messages, for instance when a pattern matches * (Kleene star), meaning 1 or more instances of a single message.
  • Summary – defined by the Pattern Expression and can be used to indicate more information about a pattern. You can configure this field as needed when you are creating your own Pattern Expression.
  • Timeline – a chart that shows where a Pattern Expression’s messages occur over the timeline of a set of trace results data. In the case of the TCP Three-Way Handshake, the handshake messages occur fairly close to each other.

TCP Three-Way Handshake Pattern Fields – any pattern can be developed to expose many characteristics that are based on the fields of captured messages. This could mean exposing a single field or even an expression based on multiple fields across multiple messages. In the case of the TCP Three-Way Handshake pattern expression, you can use these fields to analyze the characteristics of each connection:

  • AproxRTT – an approximation of the round trip time, which helps you understand the latency involved with a connection. This value is calculated as the time difference between the first two messages. This is a good heuristic measurement because servers are typically tuned to respond quickly to Syn packets. However, should there be any latency due to a slow server response, this is still important information to know.
  • Source/Destination address – based on the Source initiating the Syn.
  • SourcePort/DestinationPort – based on the Source initiating the Syn.
  • ServerMaxSegmentSize – the allowed packet size that the TCP server can send. Values less than 1460 might indicate issues, such as black hole routers or performance problems.
  • ServerScaleFactor – the scale factor set by the server which is required to calculate the Window Size scale. While TCP uses a word size to set the window size reported, the scale factor is an adjustment which multiplies the window size and this allows window sizes that are greater than those that can be represented by a single word.
  • ServerSackPermitted – a TCP value that indicates where the connection will support Selective Acknowledgements. SACKs can improve network performance by allowing more than one segment of TCP sequences numbers to be incomplete.
  • ClientScaleFactor – the client size scale factor, which can be different than the server.
  • ClientMaxSegmentSize – the allowed packet size that the TCP client can send. Values less than 1460 might indicate issues, such as black hole routers or performance problems.
  • ClientSackPermitted – the client can have a different number of unacknowledged segments.

By analyzing these values, you can better understand performance issues. For instance, by looking at the ApproxRTT value, you can correlate bad performance from a specific endpoint with a large RTT. Segment sizes less than 1460 are often a red flag and is something you might need to investigate, especially if it correlates to a machine or service that is experiencing problems. A scale factor value at zero is often an issue with older systems, or ones that have been misconfigured. Modern systems typically use a scale size of 7 or 8. SACKS are often set to 2 these days, but again could be misconfigured and cause a performance issue.

Baselining is another way you can use this Pattern Expression. When things are humming along nicely, you can take a capture and get a snapshot of what some good values look like. Then, when a performance issue arises, you can compare and try to understand what has changed.

Pattern Power

I continue to find scenarios where patterns can be employed to discover and explore complex traffic, often adding insight into what otherwise would be a crap shoot. With the new Pattern Editor UI, which I haven’t talked about yet in a blog, we are hoping that pattern creation is even more accessible. Together, we can create patterns to illuminate the most difficult issues and share this tribal knowledge, which until now there was no way to systematically express.

More Information

To learn more about building Pattern Expressions, see the following:

Pattern Match Viewer — a section in the Message Analyzer Operating Guide that includes detailed content about the new Pattern Match viewer.

Using the Pattern Editor — explains how to use the Pattern Editor with or without UI automation support; also provides a simple example of building a Pattern Expression.

Sequence Match View: Identifying Interesting Network Patterns — an earlier article on the Message Analyzer Blog site.


Comments (2)

  1. WesE says:

    This is a great feature. The three-way handshake response is particular useful for separating network response time from application response time.

    Thanks for the explaining it feature.

  2. Anonymous says:

    Because Message Analyzer enables you to see multiple views of the same data in a session and message

Skip to main content