A single PMUX can run many different probes. However, it is good practice to separate capture probes and stack probes into separate PMUXs. This ensures that, if something goes wrong with a decode, you have an independent capture from the other PMUX.

These are the PMUX processes that you’d see running in a typical simple system:

The naming of VP and capVP is arbitrary - the definition of the probes defines the overall function of the PMUX. VP is short for Visibility Point.

Start by defining the list of PMUXs that will run by editing <confdir>/vmx-servers.cfg.
For example, to run the above DRAKE_VP PMUX on the valentine01 server, add the following to this configuration file:

Then configure each PMUX in bindir/env-instances.sh.
For example:

In the above example DRAKE_VP is the name of the PMUX that is being configured.

The -s 6 argument for KALEID_DRAKE_VP_ARGS instructs the PMUX to process the traffic from Napatech stream 6. See VMX-Capture Capture Card Configuration for more information on Napatech stream information.

PMUX Types - File-reading versus Napatech

There are multiple types of PMUX. The type is defined by the value of the KALEID_<INSTANCE ID>_VP_PATH environment variable.

The two main types that we will consider in this document are the Napatech PMUX and the file-reading PMUX.

The advantage of the Napatech PMUX is that the PMUX reads directly from the card, so it doesn’t need the data to be written to disk in order to process it. The downside of this approach is that the PMUX (and any probes within it) has to be able to keep up with the volume of data sent to it - there is no buffering beyond the deep hardware buffers that the Napatech card provides. This will be fine for a capture PMUX but if your stack probes offer a lot of functionality,  they may not keep up with particularly high intensity bursts. For particularly bursty financial markets feeding into a particularly complicated stack probe, we usually recommend a file-reading PMUX.

The Napatech PMUX reads data directly from a Napatech card.

Here is an example env-instances.sh configuration for a Napatech PMUX:

The ‘-s 1’ argument tells the PMUX to process packets directly from Napatech stream 1 (see VMX-Capture Capture Card Configuration for details of Napatech stream configuration).

The file-reading PMUX reads data from a PCAP file in a defined read_directory. Here is an example env-instances.sh configuration for a file-reading PMUX:

Normally, the PCAP files would be written there by a Napatech PMUX. However, the file-reading PMUX can also process PCAPs written by other capture processes, or by other capture cards.

It is possible to use the read parameters to set up the file-reading PMUX and instruct it to read the files at regular intervals. However, we recommend the standard configuration, which is to use the ipolling mechanism. The ipolling mechanism prompts the operating system to notify the PMUX as soon as a new file becomes available.

So, if we take our example system above:

You would expect to see (as a minimum) the following parameters in the env-instances.sh file:

This configures the capVP PMUX as a Napatech PMUX (consuming packets from Napatech stream 1) and VP as a file-reading PMUX. More detailed configuration is then performed at the Probe level.

Configuring which probes a PMUX will load

Once a PMUX starts, it loads probes that will perform particular tasks. The PMUX determines which probes will be loaded by checking an exclude list and include list in the env-instances.sh files.

The table below details how to create the exclude and include lists in env-instances.sh.

The following formats are supported for the list of probes:

• “probe_name1” means probe_name1.stack.json will be loaded (or excluded)

• “probe_name1 probe_name2” means probe_name1.stack.json and probe_name2.stack.json will be loaded in that order (or excluded)

• “*net*” means load or exclude all configs that match the glob pattern *net*.stack.json

• “*net* *md*” means load or exclude all configs that match either glob patterns *net*.stack.json or *md*.stack.json