Response time analysis

From Allegro Packets Product Wiki
Jump to navigation Jump to search

The Response time analysis allows to track protocol requests and responses in virtually any network protocol. It is possible to add protocol definitions with any number of different requests and different responses. The system analyses the traffic and searches requests or responses based on the configured patterns. Whenever a requests occurs, the system counts the event and stores the time of the packet and when a response happens, the response time is stored. A graphical representation allows to track response times for every possible combination of requests and responses as well as additional counters for requests that have not been answered or responses that have not been requested.


Features

  • multiple protocol definitions possible
  • each definition can have any number of requests or responses
  • layer 7 protocol filter may be used to limit the network traffic that needs to be analyzed
  • Requests or responses can use one or multiple patterns to describe individual protocol requests or responses.
  • Patterns may be joined with AND or OR operation.
  • Textual patterns or hexadecimal representation of data can be used.
  • Offsets or ranges can be used to configure a fixed position to search for a pattern or a range of bytes to search for a pattern.


Limitations

Since the response time analysis is generic no specialized knowledge about the protocol is available. Therefore the following limitations apply:

  • Pipelining of requests or responses is not supported. That means that for a request a response must happen before the next request is processed. If there are more than one request in a row, it is interpreted as a lost response. If there are more than one responses in a row, it is interpreted as a lost request.
  • The data pattern to identify requests or responses must occur within a single network packet. Additional data packets before the response are supported as long as the pattern does not re-occur.
  • TCP retransmissions or out-of-order TCP packets are currently handled as regular packets thus possibly triggering additional events.


Available statistics

Global statistics

The global statistics tab sums up all measured response times for every IP on the network.

Field Meaning
Number of matching replies This number accounts all seen request-response pairs, so that for a request any of the defined responses have been seen.
Number of unanswered requests Every request that got no response is accounted in this number.

This means that either the response never came and another request has been sent, or the response has been lost in the network.

Number of unrequested responses This number accounts the number of responses for which no request has been seen.

Possible reasons are that the response has been re-transmitted or otherwise was wrongly sent.

Average response time For each matching reply (i.e. a request-response pair), the time between the request and response is measured and the average value is shown in this value.
Minimum response time This is the minimum time between a request and a response ever measured in the network.
Maximum response time This is the maximum time between a request and a response ever measured in the network.
Graphs The graphs show historical values of the values above. Individual events are shown in the graph.

If more than one request-response pairs occurred within the same second, the response time is accumulated in the single data point. An error bar indicates the minimum and maximum value within this second while the dot stands for the average value.

Below the global statistics table there is a table containing all request-response pairs including all requests without responses and all responses without a request.

  • type column: This column indicates regular responses for which a request has been detected, and noanswer for request without any known response, and norequest for responses without a known request.
  • Request protocol name column: This is the name of protocol definition for which a request has been found.
  • Request name column: This is the actual name of the request seen.
  • Response protocol name column: Similar to the request, this is the name of the protocol definition for which a response has been seen. It can happen that the name differs from the response protocol name. This is on purpose to be able to identify protocol errors which some device speaks an unintended protocol.
  • Remaining columns: All remaining columns have the same meaning as the global ones described above except that the values only represent the measured results for that specific request-response pair. The special types noanswer and norequest contains only the graph for unanswered requests and unrequested responses, respectively.


Statistics per IP address pair

The IP addresses tab shows more detailed statistics for each IP pair that has used some of the defined protocols. The individual data lines are shown for each IP that has used a defined request or a defined response and its communication partner. The same IP pair may occur two times of a request has been seen on both sides. Next to the actual IP addresses there are three columns showing all protocol definitions, and request and responses seen for that communication pair.


The following columns show the usual statistics similar to the global statistics for each IP pair:

  • Matching responses: number of valid request and response pairs
  • Unanswered requests: Requests for which no response has been seen
  • Unrequested responses: Responses for which no request has been seen
  • Avg/min/max response time: The time between the request and the response, for matching request/response pairs.
  • Graph: The historical, graphical representation of all occurred request/response events.

By clicking on either the request IP or the response IP, the detailed view for this IP pair is opened. This detailed view contains the same information as the global view. First there are the accumulated numbers of request and response and the response time. Second, the table at the bottom shows the individual request/response pairs and its counters and graphical data. For detailed description see the section for the global statistics above. The PCAP button on top of the page allows to capture the traffic for this IP pair. This traffic potentially contains more traffic than just the requests and responses.


Configuration

The configuration tab allows to configure protocol definition Each protocol definition consists of the following parameters:

  • Name: this is the identifier used in all statistics.
  • Layer 7 protocol filter: Pattern search is an expensive operation. Therefore it is possible to limit the analysis to a specific layer 7 protocol only. This can be any predefined layer 7 protocol or any of the custom protocol which can be used to define a specific IP or port range.
  • Requests: A protocol definition can have any number of requests defined by a list of patterns.
  • Responses: A protocol definition can have any number of responses defined by a list of patterns.


Web interface

The following actions are possible in the configuration tab:

  • adds a new protocol and opens the configuration mask for it.
Plus.png
  • removes the specific protocol definition.
Minus.png
  • opens the configuration mask for that specific protocol definition.
Edit.png
  • This button make the changes permanent and take effect. A success or error messages will appear indicating the result of the operation.
Save.png
  • This button undo all configuration changes and restores the currently active configuration.
Reload.png
  • This buttons allows to save the current configuration to a local file for later import.
Download.png
  • This button imports the configuration file selected with the Choose file button into the browser configuration.
The imported configuration must be saved to take effect.
Import.png
  • This button resets all previously gathered statistics. It is recommended to reset statistics after make significant changes to the configuration, especially when removing some element (a pattern, a request, or a complete protocol definition). If the statistics are not reset the web interface may show invalid names.
Reset.png

Editing a protocol

The configuration mask for a protocol definition allows to configure the specific requests and responses that should be identified by the system.

  • Name: this is the identifier used in all statistics.
  • Layer 7 protocol filter: Select a layer 7 protocol to limit the analysis to network traffic of that protocol. This improves the performance allowing to analyze with a higher bandwidth. It can also reduce false hits when a pattern is found in unrelated traffic.
The top drop down box allows to select from all of the defined protocols while the bottom drop down box lists only custom protocols for easier access to such protocols.
  • Requests: Configure the list of requests for this protocol definition.
Edit.png
  • Responses: Configure the list of responses for this protocol definition.
Edit.png

Editing a request or response

The configuration mask for requests or responses allows to add any number of requests or responses. Each request or response can have any number of patterns defined which are search within the packet layer 7 payload.

The table lists all defined requests or responses.

  • The first column allows to add new elements or remove existing one:
    • adds a new request or response
Plus.png
  • removes the request or response entry from the list
Minus.png
  • The second columns allows to choose the name of the request or response.
The name is purely informational and can be chose freely.
  • The third column contains all defined patterns for each request or response.
    • This button removes the single pattern directly right of the button. All other patterns are untouched.
Minus.png
  • This button adds a new pattern to the list of patterns for the corresponding request or response. Multiple patterns are possible to use and combined by OR or AND operation. This allows to search for multiple patterns within a single packet which must occur both or any. For example, this can be used to distinguish between multiple protocol variants.
Plus.png
  • Pattern definition
Each pattern consists of the following fields to describe it:
  • Data: This is the actual data string that is searched within the packer layer 7 payload.
It is either searched as is (in case of the string data type) or converted from a hexadecimal representation.
  • Data type: The drop down box allows to select either string which is a direct representation of the data, or hexadecimal which is the byte-wise hexadecimal representation of the data.
  • Pos: This defines at which byte location the data should be searched for. It can be a single number which means exactly this position within the layer 7 payload. It can also be a range meaning the data should be search within the interval of bytes. The start value of the range is inclusive, while the end value is exclusive.
Example:
  • 0: the packet payload must start with the given data.
  • 0-10: the data must be found within the first 10 bytes of data (that is byte 0 to byte 9).
  • Join command: Except for the first pattern, the other patterns might be connected with the previous one by choosing the appropriate join command. The list is evaluated left to right without any priority so AND and OR can be mixed carefully to build complex expressions.
The pattern may either match together with the previous one (AND operation), or that the previous or the current pattern must match (OR operation).
Pattern examples:
  • data: HELLO
data type: string
pos: 0
Meaning: The pattern only applies if the text HELLO is found exactly at the start of the payload data.
  • data: 8779827668
data type: hexadecimal
pos: 10-20
Meaning: The packet payload is searched from byte 10 to byte 19 to find the 5 character data described by the hexadecimal data (the ASCII values of WORLD (87 == W, 79 == O, 82 == R, 76 == L, 68 == D).

Examples

This example describes how to measure the response time of HTTP GET requests.

  1. Add a new protocol definition by clicking at the plus button.
  2. Enter a name for this protocol definition. HTTP GET is short and appropriate.
  3. As layer 7 protocol filter select HTTP. If you only want to analyze one specific HTTP server, define a new protocol for only this IP in the L7 module and select it from the custom protocol list.
  4. Now edit the requests by clicking at the pencil button.
  5. Add a new request by clicking at the plus button.
  6. Enter the name of this request, GET is a good choice.
  7. Add a new pattern by clicking at the plus button in the third column.
  8. Enter the three characters GET (without the quotes) into the data field
  9. Make sure the data type drop down box still shows the default value string.
  10. Enter 0 (without the quotes) as the position, as the HTTP GET request always starts with the GET string.
  11. The settings should look like the following picture:
    Http get req edit.png
  12. Click at DONE to return to the previous mask for the HTTP protocol definition.
  13. Now edit the responses by clicking at the pencil button.
  14. Add a new response by clicking at the plus button.
  15. Enter the name of this response, HTTP response is a good choice.
  16. Add a new pattern by clicking at the plus button in the third column.
  17. Enter the characters HTTP/1 (without the quotes) into the data field.
  18. Make sure the data type drop down box still shows the default value string.
  19. Enter 0 (without the quotes) as the position, as the HTTP response always starts with the HTTP/1 string.
  20. The settings should look like the following picture:
    Http get resp edit.png
  21. Click at DONE to return to the previous mask for the HTTP protocol definition.
  22. The settings should look like the following picture:
    Http def edit.png
  23. Click again at DONE to finalize the configuration of HTTP protocol definition.
  24. The settings should look like the following picture:
    Http def.png
  25. Save the settings so the new definition takes effect.