Network Bridge

nProbe™ Cento features 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.

_images/cento_bridge.png

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 a subset of the one used to policy egress queues. Indeed, in bridge mode, slicing and shunting will be of no help.

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 10.0.0.0/8, one will use the additional rule

10.0.0.0/8 = 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

[bridge]
default = forward
banned-hosts = discard

[bridge.subnet]
192.168.2/24 = discard

[bridge.protocol]
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

[bridge.protocol]
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]
10.0.0.1/32 = 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

[bridge]
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.

Network Bridge Example

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

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.