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.
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.