Network Bridge

nProbe™ Cento features (in the cento-bridge binary) a bi-directional bridge mode. When functioning in bridge mode, nProbe™ Cento intercepts, policy, and (possibly) forward any traffic that goes through a pair of network interfaces. Flow export functionalities will continue to work smoothly and independently from the bridge.


nProbe™ Cento allow a fine-grained control of the bridged traffic through a set of hierarchical rules. Rules are submitted statically using a text file during nProbe™ Cento startup or dynamically via a REST API. nProbe™ Cento can be instructed to re-read the rules text file by sending a SIGHUP to the process (e.g., kill -SIGHUP <process id>). This can be useful for example to update the bridging policies without stopping and restarting the process.

The set of rules available to policy the bridged traffic is similar to the ones used to policy egress queues.

A detailed description of network bridge configuration and policing is given in the remainder of this section. The careful reader will notice a certain degree of overlap with configuration and policing of egress queues. Indeed, in an effort to keep nProbe™ Cento as usable as possible, the developers have designed a clear workflow that can be almost seamlessly used both in the context of packet bridging and in the one of egress queues.

Policing Bridged Traffic

Bridged traffic is policed though a fine-grained set of hierarchical rules. Rules can be applied at three different levels, namely:

  • At the level of bridge;
  • At the level of subnet;
  • At the level of application protocol.

Application protocol rules take precedence over subnet-level rules which, in turn, take precedence over the bridge-level rules. Bridge-level rules can be thought of as the “default” bridge rules. Policy Rules

As already discussed above, policies can be enforced at three different levels by means of rules. Rule types are two, namely:

  • Forward: forward the packet;
  • Discard: do not forward the packet;

Forward means the traffic received from a bridged network interface card (NIC) will be forwarded to the other bridged NIC as-is, without being dropped, altered, or modified. Discard means that the traffic received from a bridged NIC will not get forwarded to the other bridged NIC.

Rules are expressed as <policed unit> = <policy>. For example, one that wants to bridge all the NICs traffic will use the following expression

default = forward

Assuming an exception is needed to waive the default rule in order to drop all the traffic that originates from (is destined to) subnet, one will use the additional rule = discard

Supposing another exception is needed to waive both the default rule and the rule set on the subnet in order to always drop Viber traffic, one will add a third rule as

Viber = discard

The full list of DPI protocols supported by can be printed with

cento --print-ndpi-protocols

The Network Bridge Configuration File

Rules are specified in a plain text file that follows the INI standard. INI is a very simple standard that specify the format of the configuration file. For a more detailed introduction on the INI standard, the interested reader is referred to the section “The Egress Queues Configuration File” that follows the same standard.

nProbe™ Cento network bridge configuration files contain, between square brackets, sections corresponding to the different hierarchical levels of rules. Each section contains the rules, one per line, that have to be applied. An exhaustive example of configuration file is the following

default = forward
banned-hosts = discard

192.168.2/24 = discard

Skype = discard

In the remainder of this section is given a description of configuration file sections. As already anticipated with the configuration file example, network bridging is configured via three sections, namely [bridge], [bridge.subnet] and [bridge.protocol]. Rules are indicated in every section, one per line.

[bridge.protocol] contains application-protocol forwarding rules that must be enforced. Any application protocol is expressed using a mnemonic string. The full list of application protocols available can be queries simply by running nProbe™ Cento inline help

cento --print-ndpi-protocols

Any line in this section has the format <protocol name> = <policy>, where policy can be any of: forward and discard.

An example is

Skype = discard
Viber = discard

[bridge.subnet] contains forwarding rules that are enforced at the level of subnet. Every line in this section is formatted as <CIDR subnet> = <policy>. Subnets are expressed using the common CIDR <address>/<netmask> notation. Policy can be any of: forward and discard.

An example is

[bridge.subnet] = discard
10.10.10/24 = discard

If a flow matches both a subnet- and a protocol-level rule, then the protocol-level rule is applied.

[bridge] contains the “default” bridge policies, that is, any flow that doesn’t match any rule indicated in the subnet and protocol sections, then will be policed using the “default” rules. This section contains at most two lines, one for the default policy and the other for the policy that has to be applied to banned hosts. We refer the reader to the section “Command Line Options” for a detailed description of banned hosts.

An example is

default = forward
banned-hosts = discard

In the example above, all the flows that are not policed via subnet or protocol-level rules are forwarded as specified in the default rule. If an host belongs to the list of banned-hosts, then all the traffic gets discarded.

Note: shunting (shunt section) and slicing (slice-l3 or slice-l4 actions) rules are also supported, however they are not usually required in bridge mode as it does not make sense to use them in real world scenarios. If you are interested in configuring traffic shunt or slice in bridge mode, please refer to the syntax described in the Egress Queues (IDS mode using cento-ids) section.

Configuration Examples

Simple Bridge

Assuming nProbe™ Cento has to be used to bridge ZC eth1 and eth2 interfaces using configuration file bridge.example and banned hosts list file banned.example, it is possible to use the following command

cento-bridge -i zc:eth1,zc:eth2 --bridge-conf bridge.example --banned-hosts banned.example --dpi-level 2 -v 4

TX Offload

The bridge configuration can be optimized on selected adapters to get the best packet forwarding performance. Napatech adapters for instance support zero-copy transmission, this means received packets can be forwarded in hardware, offloading the packet copy. This support should be enabled when configuring the adapter, by using the ntpl tool, and can be combined with streams to distribute the load to multiple cores.

Please find below a sample script that can be used to configure 2 streams on port 0, and forward traffic on port 1.


/opt/napatech3/bin/ntpl -e "Delete=All"
/opt/napatech3/bin/ntpl -e "HashMode[Priority = 0; Layer4Type=TCP,UDP,SCTP] = Hash5TupleSorted"
/opt/napatech3/bin/ntpl -e "HashMode[Priority = 1; Layer3Type=IP] = Hash2TupleSorted"
/opt/napatech3/bin/ntpl -e "Setup[NUMANode=0] = StreamId==(0..1)"
/opt/napatech3/bin/ntpl -e "Setup[TxDescriptor = Dyn; TxPorts = 1; TxIgnorePos = 42] = StreamId == (0..1)"
/opt/napatech3/bin/ntpl -e "Assign[StreamId = (0..1); Descriptor=Dyn3] = Port == 0"

In order to enable TX offload in nProbe Cento, a --tx-offload option is available. In the below example nProbe Cento is configured to spaws 2 capture threads, one per stream, and forward to port 1 all traffic according to the rules configured in the rules.conf file.

cento-bridge -i nt:stream[0-1],nt:1 --tx-offload --dpi-level 2 --bridge-conf rules.conf

Sample rules configuration file for discarding video traffic from selected applications:

default = forward
banned-hosts = discard

NetFlix = discard
YouTube = discard

The Network Bridge Runtime REST Configuration API

nProbe™ Cento has been designed to allow the network bridge to be dynamically configured by means of a REST API. This API that provides the same level of flexibility that can be achieved through the configuration file.

Please refer to the API Documentation section for the full API specification.