So, Openflow doesn’t do shortest path forwarding? How can a network architecture NOT do shortest path forwarding? SDN is BS.
Yes, Openflow doesn’t do shortest path forwarding by itself, in fact, it doesn’t do anything by itself. Openflow is a tool that allows you to programmatically control your network devices.
However, it gives you the power to do it. In this post I’ll guide you through the development of a shortest-path forwarding network application using the RYU Controller and Openflow. Hopefully I’ll post a few thoughts on different forwarding schemes and Openflow.
For this tutorial, I’m assuming you are familiar with Openflow, Mininet and RYU. If you are not, go ahead and check this other posts. I’m using RYU, which is an OpenFlow Controller written in python with support to OpenFlow 1.3. To know more about it visit their website
To install RYU you can easily do
pip install ryu and BOOM! If it doesn’t work you can try using the Mininet installation script with the -y option.
The network application will be organized in three blocks:
- topology discovery
- network view construction
For the topology discovery we’ll use a RYU module/library called topology. For network view construction we’ll use an awesome python graph library called networkX. For forwarding we’ll use OpenFlow. Continue reading “Shortest Path forwarding with Openflow on RYU”
This tutorial aims to make you get in touch with some subtleties of the OpenFlow 1.3. The requirements for this tutorial are:
- Mininet 2.1 (If you haven’t installed it yet, follow this link)
- Ryu (If you haven’t installed it yet, follow this link)
- OpenVSwitch 2.0 (If you haven’t installed it yet, follow this link)
- Openflow 1.3 (If you haven’t installed it yet, follow this link)
So this tutorial will follow these steps:
- Test OVS 2.0 + RYU(OF1.0)
- Test MN user’s switch + MN controller. ( Verify it doesn’t work.)
- Test OVS 2.0 +MN controller. ( Verify it works)
- Test MN user’s switch + RYU (OF1.0). ( Verify it doesn’t work.)
- Test MN user’s switch + RYU (OF1.3). ( Verify works fine.)
- Test OVS 2.0 (OF1.0) + RYU (OF1.3)
- Test OVS 2.0 (OF1.3) + RYU (OF1.3)
- Conclude OVS 2.0 (OF1.0+1.3) + RYU (OF1.3) rules!
SO, in this tutorial we will test several scenarios. The initial problem we faced with OF1.3 was negotiation. Basically, if controller and switch don’t match versions they won’t talk, and won’t work.
I will give you the best solution in advance, then if you want to understand a lil better you can read the article to the end. The best solution is to enable OVS 2.0 switches to work with all versions of OF AND make sure RYU is running the right code.
Start ryu with OF13. (Note in line 20 of the code that Ryu imports OF13)
PYTHONPATH=. ./bin/ryu-manager ryu/app/simple_switch_13.py
sudo mn --topo linear,4 --mac --switch ovsk --controller remote
h1 ping h4
Enable OpenFlow 1.3 in the switches. ( you need to open a new terminal with xterm s1 for that)
ovs-vsctl set bridge s1 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s2 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s3 protocols=OpenFlow10,OpenFlow13
ovs-vsctl set bridge s4 protocols=OpenFlow10,OpenFlow13
The article is not finished haha, I will finish it ASAP.