Service Engineering (ICCLab & SPLab)

A Blog of the ZHAW Zurich University of Applied Sciences

Tag: openflow

SDN – OpenFlow Presentation to the IT-MAS students

17. December 2012 / / 0 Comments

Last Friday Philipp from the ICCLab gave a presentation about SDN and OpenFlow to ZHAW master students. The big difference is that the average age of the students is higher and all of them are working for many years in the field of IT. Furthermore, most of them have a leading position in their daily work. The content of the presentation is not that detailed an covers basically the two whitepapers from the ONF and openflowhub.org about SDN and OpenFlow. We also talked about the available products in the field of OpenFlow controllers and why SDN in general is such an important thing for the datacenter providers, ISP’s or Carrier Ethernet.

The discussion we had after the presentation contained also some critical voices that addressed problems like:

  • OK, we are vendor independent and have full control over the network but this means also, that we are responsible for it.
  • Is it not easier for SME’s to have a ready made network component from e.g. Cisco instead of programming the logic by themselves?
  • The centralized network controller looks like a single point of failure and without the network, most business applications will not work.
  • Will the programmed network logic inside the controller not bee a huge bunch of code that was before distributed and small on every device?

Of course, we can answer the questions and solve these problems with the SDN paradigm. But the conclusion for us is that we can only get these people on board if we not only talk about SDN concepts but present demonstrators.  What we need at this point are:

  • Concrete working pieces of code and open working network logic that is tested and maintained as e.g. spanning-tree modules.
  • Testbeds and use-cases for implementation, migration and operation.
  • Fully functional and easy to implement network controller modules.

Such people as the master students are needed because they are and/or will be the decision makers. It is also not enough to say: “Look, Google uses it in their wide area network.”

Integration and migration of our existing network infrastructure is exactly what we are planning to do at the ICCLab. I hope that more people will share their knowledge and experience about a successful migration of their classical network to a SDN based infrastructure.

OpenFlow – Setting up A Learning Switch

10. October 2012 / / 11 Comments

If you are also interested in SDN architecture and want to use the OpenFlow specification for it, a good starting point is the tutorial on openflow.org. OpenFlow has its roots at Stanford University and provides the communication between the data- and the control-plane in a SDN based network architecture. In this article we will show you how to setup a system that implements a learning switch using the OpenFlow specification.

First thing you need are OpenFlow-ready switches or, if you don’t want to buy them, a virtual switch that implements and supports OpenFlow will do just as well. For the second use-case exists a tool called mininet, with which you can create easily an OpenFlow-based SDN network topology. In this article we will use mininet, which you will need to install first or download the virtual appliance from github. We recommend the virtual appliance instead of a native installation because there are a lot of development tools also for OpenFlow in the virtual appliance.

After installing mininet just run the following command, that creates a topology with 3 hosts connected to one switch and a remote controller.

[gist id=3834980]

For the first controller use POX. POX is a easy to use control-plane to get quick first results. The POX controller is coming out of the NOX project, witch was the first controller for OpenFlow. In contrast to NOX, it has a better performance for components written in python. To install the controller itself, it’s nothing more then cloning the git repository and firing up the controller. In order to install the controller, running it and doing some first tests, have a look at the openflow.org tutorial.

When a OpenFlow-ready switch receives a package and the switch has no flowtable-entry for that package, the switch sends the package to the controller. In OpenFlow, every switch (physical or virtual) has its own flowtable. This table contains information, how the incoming package “flows” trough the network. The switch from our created topology has at the moment no flowtable-entry. Thus, we create a very simple component-class for the controller that implements learning switch logic that has the following tasks to do, if two hosts want to communicate (e.g. host-1 and host-2):

  1. A package arrives at the switch and we have no flowtable-entry that matches our package -> the package will be send to the controller.
  2. The controller performs now various checks on the package
    1. Do we know the MAC-address and the switch-port from the sender (host-1)? No, we store this information in the controller, because we know at which port the package has received and who the sender was.
    2. Do we know the MAC-address and the switch-port of the recipient (host-2)? No, we flood the package to every port from the controller.

The recipient (host-2) will send an answer to the sender (host-1) but this time the controller has already some information.

  1. host-2 sends an answer back to host-1 but we have still no flowtable-entry in our switch -> the package will be send to the controller once more.
    1. Do we know the MAC-address and the switch-port from the sender (host-2)? No, we store this information in the controller, because we know at which port the package has received and who the sender was.
    2. Do we know the MAC-address and the switch-port from the recipient (host-1)? YES, we stored it before in the controller. The controller can deliver the package at the port where the recipient (host-1) is.
  2. Now we know the MAC-address and the port of the two hosts in our controller. We can install a flowtable-entry in the switch for these two hosts

The two hosts can now send packages to each other, without the need of the controller, because our switch has learned the MAC-addresses and the ports of the two hosts. If the controller knows both hosts, he can setup a flowtable-entry in the switch. Now let us have look at the python code for the component-class in the POX-controller.

First thing we need in the controller is a component-class where an object is created for every connected switch. When switch shows up at the controller, the constructor from this component-instance will be called and a connection object for that switch will be passed to the constructor.

Next we need a launch function outside our component-class but somewhere, where POX can find it. The name of the component is specified by the command line option when the POX controller starts. Simply we put our launch function inside our component, where also our component-class MyCtrl is.

[gist id=3863852]

Inside the launch function is an eventListener attached by name. The listener expects an eventTyp, that is passed as string to the listener and a method or function witch should be called, when the eventTyp is raised. Our component-class on the other hand implements also an _handle_PacketIn function that is used to listen to the PacketIn events. These events are fired from the switch to the controller.

[gist id=3864066]

Our component-class only listens to the PacketIn event from the switch where the package is parsed and after that, passed to the logic of the learning switch. The function act_like_lswitch makes all the things discussed above:

  • Manage our macStore
  • Installing flowtable-entrys if necessary
  • Forwarding packages if necessary
  • Decide, if the switch must act as a hub

[gist id=3864113]

The two functions, self.send_packet and self.act_like_hub, will be discussed later. If we have the destination port and MAC address in our macStore list, the component-class installs a flowtable-entry in the switch. With the match structure provided by openflow, the switch then decides, witch packages has to follow the installed flowtable-entry. This is done by the ofp_match object from the ofp_flow_mod class. In this component-class, the flowtable-entry should match all packages, that arrives at a specific port on the switch with the MAC-address from the destination host. Then, the ofp_actions object appends a new action that specifies the output port for the package that targets our match. Appending the action to the ofp_actions object does not affect the switch, thus we must send the flow modification to the switch by invoking self.connection.send(fm). Do you remember, the connection object is set in the constructor of our component-class and we can use it, to send information’s like flowtable modifications to the switch. The function self.send_packet encapsulates some error handling and the logic, to send packages in a generic way to any network device in our infrastructre thus, its a helper function. The function self.act_like_hub on the other hand, encapsulates the logic for flooding packages to every port except the input port.

That’s all. Fire up the virtual network infrastructure with mininet with the command above and also start the controller with log level DEBUG as follows:

[gist id=3864371]

If we’re calling mininet> pingall in the mininet console, we can see the following output in the console where our controller is running (depends on the mnininet infrastructure)

[gist id=3864376]

By running the mininet command mininet> pingall a second time, you should see no further debug messages in the controller console. The reason for this is exact the effect we want to achieve. The switch can forward the packages now by itself and you can check with the dpctl tool the flowtable of the switch witch could look like the following:

[gist id=3864747]

This simple implementation should give you an idea, what further things can be done with OpenFlow. There are still a lot of unsolved problems in our component-class like:

  • The macStore list must be multidimensional to store the MAC addresses from more than one switch
  • Automatic handle changes at the input ports of the switch
  • A more meaningful error handling

Our next steps at the ICCLab will be configuring a physical switch for OpenFlow and use this switch with a productive controller to flow the traffic in our Lab. And of course, we will publish our experiences with OpenFlow right here on our website.