This tutorial is written for Fedora but can be applied to all rhel based systems. The only “big” thing you would need to change is the package manager command from
dnfto for example
What is OpenVSwitch
OpenVSwitch is a SDN application (Software defined networking) that allows you to create networks and switches on software level.
- At least two servers running Fedora 23 or higher (it may even work with Fedora 21 and higher, but it is not tested!).
- Root access to the servers.
- Network connectivity between the servers (the following protocols need to be allowed:
The goal of the tutorial is to create an “overlay” network between two and more servers using OpenVSwitch.
Step 1 - Installing OpenVSwitch
Do this step on all servers.
To install OpenVSwitch on Fedora 24 we use the package manager
The command to install the OpenVSwitch package is:
After the command has been successfully run, you now have OpenVSwitch installed.
First at all we have to start the OpenVSwitch service. To do that we use
systemctl (more details on how to use systemctl can be seen [here]() INSERT LINK TO COMMUNITY TUTORIAL):
Don’t enable the service yet because if you accidentally “kill” your network connection through OpenVSwitch, you can just reboot the server and the configuration will not be loaded.
Step 2 - Creating the bridge interface
Now that you have OpenVSwitch installed and the service started, you can create the bridge interface. The command for creating an OpenVSwitch bridge device is:
br0. You have now created your bridge interface. To see your bridge interface use the
ipcommand (the below output should be similar to yours):
Step 3 - Preparing for the GRE tunnels
You should now create a list of your servers and beginning from 0 a number for example like this:
A list for three servers with the interface name and IP address written behind the lines:
Your server firewall should not block the GRE tunnel protocol traffic.
For iptables the protocol name is
An example rule to allow all GRE tunnel protocol traffic:
Step 4 - Opening the GRE tunnels
Before creating the first GRE tunnels you should know that it will not make any sense if you have more than 3-4 servers to link all of them together. You should create a redundant mesh between your servers and not link all to all.
br0in the commands is your bridge device. Please change it according to your bridge name.
Starting on your the first server (IP:
184.108.40.206), we create the tunnel to the second and third server:
On the second server (
220.127.116.11) we now create the tunnel to the first and third server with the commands:
On the third server (
18.104.22.168) we create the tunnel back to the first and second server so the three server mesh is complete:
Step 5 - Adding IP addresses to the bridges
You can now add an extra field to the exisiting server list which contains the network range.
In the tutorial case the network will be
10.244.0.0/16 network, so the list looks like this:
It is important to know what servers uses which IP address to avoid address conflicts. If you changed the CIDR of the network range from the tutorial, you also have to change the broadcast address in the below commands.
Now that you have decided what server has what network slice, we can set the interface up and add the IP addresses to the bridge on each server.
On the first server (
22.214.171.124) the command would look like this:
On the second server (
126.96.36.199) the command is slightly different due to the other address:
And so on with different IP addresses per server.
Step 6 - Checking the virtual network connectivity
Now that every server has it’s own IP address in the virtual network, we can check the connectivity.
We are going to use the
ping command for testing the connectivity between the servers.
From the first server (
If you should not receive a ping response in the next 10 seconds, it may be caused by a setting called
proxy_arp in the
br0in the command(s) is your bridge device. Please change it according to your bridge name.
/etc/sysctl.conffile is loaded on every boot.
Now after that change, retry to ping and it now should work.
As long as you build a good mesh between the servers the virtual network between the servers will be redundant. But don’t over do the mesh building between the servers. As mentioned earlier too many tunnels is too much.