User Tools

Site Tools


Keeping Community Network Privacy and Stability


In order to leverage the usage of a real network, it would be desirable for any research node (RN) to be an integral part of the community network (CN). Moreover, to allow a greater range and flexibility in experiments, it should have access to the lowest possible level in the network stack. On the other hand, a RN should not be allowed (at least not without explicit permission) to interact with the CN in a way that could expose other users' data (e.g. traffic sniffing) or cause instability to the network (e.g. poisoning of routing protocols).

Under controlled environments (e.g. CONFINE cloud), this last requirement may not hold and the RN may be the physical machine itself, with access to the physical network layer (L1) and total software flexibility. However, operating in the CN requires either restricting the software to be run or its environment. This last option includes placing a firewall between RNs and the CN, and running RNs as virtual machines (VMs), but it still leaves high software flexibility and it can provide controlled access to the data link network layer (L2).

This document deals with some issues on CN privacy and stability regarding hosts running Linux container VMs (LXC) as RNs with bridged interfaces, an interesting solution since it only uses mainstream Linux features (from version 2.6.29), it is light in resources and it gives the RNs L2 access.


A Linux bridge acts as a switch, not a hub, i.e. an interface X attached to a bridge B only receives from the other interfaces attached to B unicast frames addressed to X's MAC address or multicast/broadcast frames. That means that a VM linked to its host's physical interface by a bridge would be unable to sniff CN traffic addressed to particular nodes other than itself. However, it may still be able to see multicast/broadcast traffic by default. See below for a way of avoiding this.

Bridges provided by Open vSwitch exhibit the same behaviour.

Traffic filtering

Thanks to the bridge-nf infrastructure, all IPv4, IPv6 and ARP traffic traversing a bridge can be sent through the host's ip(6)tables and arptables (toggled using /proc/sys/net/bridge/bridge-nf-call-{ip,ip6,arp}tables). This allows for extensive filtering and manipulation of L3 traffic. For instance, setting iptables' filter/FORWARD policy to DROP blocks all IPv4 traffic to VMs connected to a bridge even if they are in the same IP network as the host.

Filtering at the data link layer can be accomplished using ebtables in the host, using the VM's MAC address or its veth device name in the bridge to refer to a LXC VM, e.g. ebtables -t filter -A FORWARD -o veth1 -j DROP.

Traffic traversing a bridge provided by Open vSwitch bypasses kernel traffic filtering, but it seems that OpenFlow rules can be used for basic filtering1.

Traffic control

Controlling the traffic going in and out of an LXC VM is possible using Linux's QoS infrastructure via iproute2's tc command on the host.

Classification of all frames related with a VM (for shaping outgoing traffic on the host's interface or incoming traffic on the VM’s veth interface) can be done by marking them N with ebtables and filtering on handle N fw with tc (see this example). Classification can affect all VM packets from L2 upwards (not just IP ones) by specifying protocol all to tc.

Traffic control can also be used to introduce emulated traffic disturbances (delays, jitter, reordering, duplication, corruption…) using Network Emulation. More advanced shaping can be performed using the Intermediate Functional Block.

Traffic traversing a bridge provided by Open vSwitch bypasses kernel traffic control, but basic ingress policers can be attached to ports besides some queue disciplines included with Linux2.


Standard Linux traffic filtering (using {ip,ip6,arp,eb}tables) and traffic control (using tc and ebtables) provide the necessary mechanisms to preserve the community network's privacy and stability for hosts running LXC virtual machines with bridged interfaces even when they are all part of the same network.

  1. As mentioned here. I wasn't able to find more documentation on the subject. 

  2. There are examples of this in this presentation. I wasn't able to find more documentation on the subject. 

soft/network-privacy.txt · Last modified: 2012/04/30 10:13 by ivilata