Create virtual network devices on a KVM- and OpenVZ- based Linux VPS

There are numerous ways to create your own bridge.

One way is using VDE (Virtual Distributed Ethernet) which will be covered by this article. All the steps described here work perfectly on a local Linux installation as well as on OpenVZ- and KVM-based VPS (Virtual Private Server) environments.

VDE consists of the following main components.


  • VDE switch:
    Like a physical ethernet switch, a VDE switch has several virtual ports where virtual machines, applications, virtual interfaces, connectivity tools and – why not? – other VDE switch can be virtually plugged in.
  • VDE plug:
    It is the program used to plug into a VDE switch. Data streams coming from the virtual network to the plug are redirected to standard output and data streams going to the VDE plug as standard input are sent into the VDE network.
  • VDE wire:
    Any tool able to transfer a stream connection can become a VDE wire (e.g. cat, netcat, ssh and others).
  • VDE cable:
    VDE components are interconnected via VDE cables that are made of one VDE wire and two VDE plugs as happen in a physical ethernet network.
  • VDE cryptcab:
    Informally VDE encrypted cable. Although it is possible to use tools like ssh or cryptcat to obtain an encrypted wire to interconnect VDE plugs, these tools work with connection-oriented streams to provide encryption, resulting in nested connection-oriented streams with poor performance and unjustified overhead. The idea behind cryptcab is the adoption of connectionless protocols to provide encrypted cables facility.

Why would you want to create virtual bridges?

As a showing example they allow you to experiment with networking components and study how networks actually work without physical equipment. That said you can play around with it without the need of real cables, switches and computers. More importantly you won’t break anything or disrupt your neighbourhood network segments.

Another example is to attach virtual machines to them to interface with other virtualized systems but also with real hosts over the internet.

Install VDE

On most Linux distributions VDE is available in the vde2 package.

Distribution Command
Arch Linux pacman -S vde2
Debian/Ubuntu aptitude install vde2
Fedora/Mandriva/OpenSuse yum install vde2

Check the availability of TUN/TAP

Before we continue with VDE we should check if /dev/net/tun exists. If it doesn’t, we have to create it.

mkdir -p /dev/net
$ mknod /dev/net/tun c 10 200
$ chmod 600 /dev/net/tun

Now test if the TUN/TAP device is available. Run cat.

$ cat /dev/net/tun

If the output looks like …

cat: /dev/net/tun: File descriptor in bad state

… the TUN/TAP device is ready for use or if you get …

cat: /dev/net/tun: No such device

… the device obviously wasn’t successfully created. In this case ask a serverfault expert for support.

We assume your device is ready.

Creating virtual devices

Let’s create two virtual network devices.

$ vde_switch -tap tap0 -tap tap1

Run ifconfig -a to see if it worked. Both, tap0 and tap1 should appear in the list.

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:43942 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43942 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:13438134 (12.8 MiB)  TX bytes:13438134 (12.8 MiB)

tap0      Link encap:Ethernet  Hardware Adresse 56:39:0d:9b:1c:a2  
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tap1      Link encap:Ethernet  Hardware Adresse 2a:5c:b0:51:72:8e  
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

It’s time to give them an IP.

$ ip addr add 10.0.31.10 dev tap0
$ ip addr add 10.0.31.11 dev tap1

The devices are ready now.

Assign an IP range

Nothing simpler than that. Just append /16 to the IP.

$ ip addr add 10.0.31.10/16 dev tap0

Be chatty

Let’s play with the multipurpose relay tool socat and establish two bidirectional byte streams in two different shells.

Type in one shell …

$ socat - TCP-LISTEN:4234,bind=10.0.31.10

and in the other …

$ socat - TCP:10.0.31.10:4234,bind=10.0.31.11

At this point you can easily send you text from one shell to the other.

Good luck with socializing with yourself.

Other utilities

Other utilities that provide the same feature set and more:

Coming soon

In next week’s article Install Docker on Debian-based VPS I’ll introduce docker-based Linux containers. Docker allows you to specify your very own bridges so consider this article as the first preparation.

1 Comment

  1. Chris

    Hi there,

    This morning I noticed some improvements in the way that Travis build workers (which are of course Ubuntu 12.04 Servers running on OpenVZ) handle installing Docker (ie they don’t just bomb out at the apt-get install stage any more), so I was applying these workarounds to see if I could convince Travis build workers to run a Docker image build.

    My steps are roughly:

    sudo apt-get -y install vde2
    => this is okay

    sudo cat /dev/net/tun
    => cat: /dev/net/tun: Operation not permitted

    sudo vde_switch -tap tap0
    => vde_switch: Failed to open /dev/net/tun Operation not permitted
    => vde_switch: ERROR OPENING tap interface: tap0

    Interestingly if you run mkdir -p /dev/net it reports that /dev/net already exists, so that suggests Travis is not completely out of the running on this. Any ideas that could convince that vde_switch command to work? I’m already running as sudo, but of course the default Travis user may not be in certain required user groups, or selinux could have locked this down, or… many possibilities here.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>