Running OpenFlow on a PC? - openflow

I have a question about the running of OpenFlow switch:
If we want to run OpenFlow on such a PC or a router to work as an OpenFlow switch, what should we do for that?, and is the CPU type or platform of that device important? does it make any difference?
thanks in advance.

Before you try anything on a PC, Install Open vSwitch on a VM(probably Ubuntu) and try its OpenFlow functionality.
To install Open vSwitch(OVS) on ubuntu,
sudo apt-get install openvswitch-switch
You could get a controller like Floodlight or Ryu SDN framework to act as the controller for your switch.
Here is an OpenFlow tutorial. It is outdated but still informative http://archive.openflow.org/wk/index.php/OpenFlow_Tutorial
Or you could also try mininet as #EricSorensen suggested in the previous answer. Mininet allows you to simulate a network with hosts and switches.
While using mininet, you could use its inbuilt 'nox' controller. I'd prefer floodlight though.
Hope it helps!

This is all you need: http://mininet.org/
Check the downloads and tutorial. Use either a Virtual Machine, or native install from source (on Linux)

you can install openvswitch or use ofsoftswitch13 from https://github.com/CPqD/ofsoftswitch13 in a linux based PC with at least two physical interfaces.so that the packet routing can see.
Also using mininet https://github.com/mininet/mininet can run OF (for this one interface is enough) which supports the creation of various network topologies.

As suggested for testing you can simply do a apt-get install or similar on most recent Linux distros. There are two components to openvswitch, a kernel module and the user space openvswitch. The user space process does not require any specific number of cores or processor type and for the most part you can do with less than a core.
Apart from ovs you also need ovsdb, which apt-get install or similar will automatically set up for you (hence the easiest way to go about it). Again pretty lightweight its just a json key-value db.
For the controller there are a lot of options but for playing around you can use the built in command line tools as well.
ovs-apptctl: To setup the switch http://openvswitch.org/support/dist-docs/ovs-appctl.8.txt
ovs-oftcl: To add/mod/flows http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt
ovs-dpctl: To see the kernel flows
I would highly recommend getting a feel for the command line tools, OpenFlow commands and how flows work before picking Pox, Daylight etc.
Apart from mininet there is also Oftest (https://github.com/floodlight/oftest) that is primarily used to write tests for openflow but its pretty useful to learn and debug issues in a constrained environment.

Running OpenvSwitch
If you want to build OpenvSwitch with bare metal, I suggest you use official tarball to install OpenvSwitch daemon.
Please follow this step:
#/bin/bash
# In root permission
aptitude install dh-autoreconf libssl-dev openssl
wget http://openvswitch.org/releases/openvswitch-2.4.0.tar.gz
tar zxvf openvswitch-2.4.0.tar.gz && cd openvswitch-2.4.0
./boot.sh
./configure # If you want to build kernel module, please append --with-linux=/lib/modules/`uname -r`/build
make modules_install
modprobe gre
modprobe openvswitch
modprobe livcrc32c
ovsdb-tool create /usr/local/etc/openvswitch/conf.db /usr/local/share/openvswitch/vswitch.ovsschema
ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach --log-file
You can use ovs-vsctl show of ovs-ofctl show to check OpenvSwitch status. Next step, we need to add physical or logical (likes veth pair) interfaces to OpenvSwitch bridge
# Create OpenvSwitch is named 'ovs-br'
ovs-vsctl add-br ovs-br
# Add interface to OpenvSwitch bridge
# If you want to check, please use `ovs-vsctl` to check again.
ovs-vsctl add-port ovs-br eth0
# Set OpenFlow controller
# You should ready one controller
# If not, I have two installation solutions can give you
# Ryu installation: https://github.com/sdnds-tw/ryu-installer
# ONOS installation: https://github.com/pichuang/onos-ansible
ovs-vsctl ovs-br set-controller tcp:x.x.x.x:6653
# Use ovs-vsctl to check controller attribute is UP

Once you let another server(here we call it controller) to determine the packet forwarding behavior of your local machine (here it is your PC), it turns into so-called SDN mechanism. So it's not relevant what kind of CPU or hardware you are choosing, basically, you can consider SDN as a software solution.
For the process to install the SDN-enabled software, you can choose open vswitch which has been answered in the above posts.

Related

Qemu 5.2 - nothing shows up after VNC running

i'm trying to use QEMU 5.x for research.
I got QEMU 5.2 source code from qemu.org and installed following instructions.
However, when i tried to run VM by this command:
qemu-system-x86_64 \
-monitor stdio \
--enable-kvm \
-m 4096 \
-cdrom ubuntu-20.04.iso \
-drive file=img.qcow,if=virtio \
-boot c
-rtc base=localtime \
-device virtio-keyboard-pci \
-vga virtio \
then the following texts are printed:
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) VNC server running on 127.0.0.1:5900
then nothing shows up, while QEMU 4.x (used before) pops up a window showing guest ubuntu's GUI.
I'm using ubuntu 20.04. Hope anyone has breakthrough for this..
The message says that this QEMU is using the VNC protocol for graphics output. You can connect a VNC client to the 127.0.0.1:5900 port that it tells you about to see the graphics output.
If what you wanted was a native X11 window (GTK), then the problem is probably that you didn't have the necessary libraries installed to build the GTK support. QEMU's configure script's default behaviour is "build all the optional features that this host has the libraries installed for, and omit the features where the libraries aren't present". So if you don't have any of the GTK/SDL etc libraries when you build QEMU, the only thing you will get in the resulting QEMU binary is the lowest-common-denominator VNC support. If you want configure to report an error for a missing feature then you need to pass it the appropriate --enable-whatever option to force the feature to be enabled (in this case, --enable-gtk).
If you're running on Ubuntu and your apt sources.list file has deb-src lines in it, the easiest way to install all the dependencies that would get you the same feature list as the real Ubuntu QEMU package is to run "apt build-dep qemu". I recommend that you do that and then re-build QEMU, passing --enable-gtk to configure so you can confirm that the necessary dependencies were installed.

How are the --network options available in podman?

I am running a virtual environment on CentOS with podman.
When I used the --net option of the podman run command, I get an error.
[user#server ~]$ podman run --net slirp4netns:port_handler=slirp4netns -p 1080:80 -d --name web nginx
Error: cannot join CNI networks if running rootless: invalid argument
Is this option unavailable?
Or is there a problem with the way the options are specified?
Please tell me solution.
I used this site as a reference for the command.
This is the configuration of the server.
[user#server ~]$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)
[user#server ~]$ podman -v
podman version 2.0.6
The port_handler option requires Podman >= 2.1.0, which isn't released at this moment: https://github.com/containers/podman/commit/d86bae2a01cb855d5964a2a3fbdd41afe68d62c8
You can use that option if you compile Podman from its master branch.
I find this link quite helpful to see rootless communication :
https://www.redhat.com/sysadmin/container-networking-podman
https://podman.io/getting-started/network
I am not sure if you have seen this link before or even if it is helpful to you at this instance. But, in view of helping others out, I think the blog post quotes the following helpful statements:
Note: All podman network commands are for rootfull containers only.
Technically, the container itself does not have an IP address, because without root privileges, network device association cannot be achieved
When using Podman as a rootless user, the network is setup automatically. The container itself does not have an IP Address, because without root privileges, network association is not allowed. You will also see some other limitations.

how to forward packets to OpenDaylight controller

i use Open vSwitch and OpenDaylight.i want to forward packets to controller. what i want to do is build a firewall, so ovs first send all packets to controller, and the controller will judge whether the packet should be blocked or not.
i add following code in datapath/datapath.c/ovs_dp_process_packet()
struct dp_upcall_info upcall;
int error;
memset(&upcall, 0, sizeof(upcall));
upcall.cmd = OVS_PACKET_CMD_MISS;
upcall.portid = ovs_vport_find_upcall_portid(p, skb);
upcall.mru = OVS_CB(skb)->mru;
error = ovs_dp_upcall(dp, skb, key, &upcall, 0);
what i want to do is upcall the packets to controller even if they match the flowtable. but after i complie the code, it doesn't work. so how to upcall packets to controller ?
OVS:
Adding a new action to OVS is a long story that you can follow. here is a list of most important code files that you should change:
lib/ofp-actions.c: Defining new action, encoding, decoding and formating
include/openvswitch/ofp-actions.h: propagating action
datapath/linux/compat/include/linux/openvswitch.h: defining in kernel level
lib/odp-util.c: defining action's bytes length
ofproto/ofproto-dpif-xlate.c: this file handles comunication between kernel and userspace. specifically when there is no match for a new flow
datapath/flow_netlink.c: define action's bytes in kernel
datapath/actions.c: execution action
For complete steps, I highly recommend following Custom Open vSwitch Actions
After changing in source files use these commands in the root directory of OVS to stop, make and run it. be careful that your gcc version should be the same as the version that your Linux header files have been compiled.
ovs-ctl stop
ovs-dpctl del-dp ovs-system
rmmod openvswitch
make clean
make modules_install clean
./boot.sh
./configure --with-linux=/lib/modules/`uname -r`/build --enable-Werror
make
make install
make modules_install
config_file="/etc/depmod.d/openvswitch.conf"
for module in datapath/linux/*.ko; do
modname="$(basename ${module})"
echo "override ${modname%.ko} * extra" >> "$config_file"
echo "override ${modname%.ko} * weak-updates" >> "$config_file"
done
depmod -a
modprobe openvswitch
lsmod | grep openvswitch
mkdir -p /usr/local/etc/openvswitch
ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
mkdir -p /usr/local/var/run/openvswitch
ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach --log-file
export PATH=$PATH:/usr/local/share/openvswitch/scripts
ovs-ctl start
Controller:
In the controller, you should be able to create and push Action to switch. I have no information about the way of defining new Action in OpenDayLight but, I know that in Floodlight it is achieved by using Loxigen.
If you had any problem, feel free to contact me.

qemu is not able to boot u-boot uImage binary

I've used buildroot to build a qemu compatible Linux kernel and root filesystem. I am emulating for the MPC8544DS machine and used the qemu_ppc_mpc8544ds_defconfig to generate these components. I was able to successfully build the kernel and the root filesystem. And was able to run it under qemu.
However when I tried to run uboot instead of the Linux Kernel (and the associated rootfs) it fails. Here is the way I invoke qemu to boot u-boot:
qemu-system-ppc -nographic -M mpc8544ds -m 512 -kernel ~/CrossCompilation/u-boot.bin and it fails like so:
Wrong image type 52, expected 2
qemu: could not load kernel '~/CrossCompilation/u-boot.bin'
I do not understand what else could be wrong. I've checked various blog posts over the internet and almost all of them use uboot.bin as the kernel (as opposed to srec and other formats)
could someone shed some light on the various image type numbers and which ones fit where?
UPDATE: This is how I compiled my u-boot
cd to u-boot dir
make distclean
make mrproper
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe- MPC8544DS_defconfig
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe-
Try removing the -kernel option. Make sure everything stay as is:
qemu-system-ppc -nographic -M mpc8544ds -m 512 ~/CrossCompilation/u-boot.bin

libvirt and VirtualBox / Getting Started

I'm trying to get started on libvirt with VirtualBox as a virtualization solution. I installed everything and VirtualBox itself is running when using their VBoxHeadless command.
However, libvirt fails to connect to VirtualBox:
# virsh -c vbox:///session
libvir: error : could not connect to vbox:///session
error: failed to connect to the hypervisor
I could not find any hints in the libvirt documentation that point to whether I have to make any domain specific configuration before using virsh.
Does anyone have a hint? Or even better, maybe a tutorial that works through the way of using libvirt, virsh or it's APIs (my later goal) from the ground up.
If you are doing this on Ubuntu, then the problem is their libvirt package is built without VirtualBox support.
You can rebuild the package with support very easily. Something like:
apt-get source -d libvirt
sudo apt-get build-dep libvirt
dpkg-source -x libvirt*dsc
Go into the libvirt directory and edit debian/rules so that instead of --without-vbox it says --with-vbox. You can add an entry to the top of debian/changelog so the package is compiled as a different version (e.g., append ~local1 to the version).
dpkg-buildpackage -us -uc -b -rfakeroot
You'll get new .debs built in the directory above. Use dpkg -i to install the relevant ones (libvirt0, libvirt0-bin, and whatever else you want).
Double-check whether or not you have write access to /var/run/libvirt/libvirt-sock.
The socket file should have permissions similar to:
$ sudo ls -la /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 2010-08-24 14:54 /var/run/libvirt/libvirt-sock
I think it could be helpful also to increase the libvirt logging capabilities by running this in your shell:
export LIBVIRT_DEBUG=1
There is Ubuntu PPA for libvirt with VirtualBox support: https://launchpad.net/~cxl/+archive/ubuntu/libvirt