Packet Filtering

We saw in Capture Probe Configuration how a capture probe can have an optional filter parameter which determines which subset of all of the PMUX traffic it will process.

This filter is also used in Stack Probes, and as there will likely be more stack probes than there are Capture Probes (each Stack Probe processes a separate network protocol stack), the filter becomes more important in determining which Probe will process which traffic.

The filter is most commonly written using BPF syntax. Beeks have developed an alternative filter protocol for cases where BPF syntax is not sufficient to define the traffic of interest, or to simplify cases where the BPF syntax is overly complex. For more information about the filter syntax see Appendix: Filter Configuration .

The BPF filter defined at the PMUX level (see PMUX Configuration and VMX-Capture Capture Card Configuration ) must be configured for a superset of the traffic that the stack will process, otherwise the stack will not receive the traffic to process it.

Although it is mandatory to include a filter for each stack probe, the filter can be left empty if you want the stack probe to process all of the traffic that the PMUX makes available to it.

This is the start of an example Stack Probe configuration, and you can see that the very first value that needs to be defined (after the name of the probe) is the filter:

Decoding

The stack uses decoders to decode the data. Data is passed up the stack, allowing multiple protocol layers to report separate statistics as part of the same stack. This stacking makes it easy for a decoder to deal with the encapsulation of different network protocols.

The decoders used are defined in the protocols section of the stack configuration. defined set of protocols to decode the data. These decoders are ‘stacked' on top of each other. The lower levels of the stack process data, and they progressively ‘unwrap’ the packet (in the case of the protocol layer). The sequencing of these protocols is therefore important.

For example:

In the example above, the standard ethernet decoder starts processing the packet, and when this is done it passes the packet up to the Arista2 decoder.

The Arista2 layer processes the Arista timestamp in the packet (this is optional - it is not required if the native Napatech timing of the VMX-Capture appliance is being used. Other third-party timestamps can be decoded).

At the IP and sbe_otf layers, there is the first element of personalisation where the ‘myIP’ and ‘dec_sbe’ module IDs are introduced. This stack configuration will have a ‘myIP’ section which will provide additional definition specific to this part of the packet processing. In many cases, there will be no need to alter the default behaviour of the chosen protocol decoder so the ‘myIP’ section (or equivalent name) may be missing. However, see Worked Example: TCP Round-trip time stats in Beeks Analytics for Markets for an example of where the IP decoder behaviour is modified within the configuration file.

Note that the IP protocol decoder also covers many other protocols - most notably TCP, UDP and ICMP. It however be configured in passthrough mode so that it only processes the IP layer - this is useful for when you want statistics about another IP-based lower level protocol.

The SBE (Simple Binary Encoding) and ACD (Advanced Configurable Decoder™) are examples of decoders that you can customise for your own purposes, using a simple file definition to define the fields that will be decoded. There is also a typescript SDK available to completely write your own decoder from scratch, including bespoke on-the-fly data manipulation.

For more information on these other decoders, see the Beeks document Beeks Analytics Decoder Information. This document is also the reference point for all of the decoders that are available. Beeks provides over 100 decoders for different financial markets and enterprise protocols.

Configuring the probes for different Packet Brokers

Packet brokers (also known as packet aggregators) are often used to ‘fan in’ network information to Beeks Analytics. They often add a layer of packet metadata to provide extra information about each packet, for example, the timestamp that they received the packet or the port that they received the packet on.

Beeks Analytics has the advantage over other tools in that the stack probes can be configured to read this packet metadata even if it is stacked within the packet, or if Beeks Analytics is receiving packets from multiple different packet brokers on the same physical appliance port.