Thanks to all who joined us on April 11 for the SDxCentral/ONF webinar on OpenFlow. And a special thanks to software architect Andrew Pearce for sharing key lessons he learned when he was coming up to speed on OpenFlow. Pearce’s demo laid out the fundamentals of how to design and develop an OpenFlow network app on the OpenDaylight controller.
Pearce took questions from participants after the presentation, and that Q&A follows. If you missed the webinar, you can watch the full presentation or check out the teaser video and other resources below.
Did you look at writing the application on other controllers? Why did you consider only OpenDaylight?
Andrew Pearce: We decided to use the OpenDaylight controller because its development is supported by several major equipment vendors, it has a large number of developers working on it, and it seems to be emerging as the standard controller for many different applications. While there were other controllers available in the open-source world, it seemed to us that OpenDaylight had a lot of momentum at the point we picked it.
Does the tap aggregation software you have only work with one switch, or will it support multiple switches?
Pearce: The design supports cascading of switches by sending the captured traffic to an upstream switch where the capture device is connected. However, we have not implemented this. If any developer is interested in doing so, they should look at the NextHopSwitch object as a starting point. Note that there might be some complexity around implementing the next-hop logic due to challenges such as overlapping source/destination addresses in programming the flows. All these challenges can definitely be overcome with some effort.
Are you planning on extending this to OpenFlow 1.3?
Pearce: We have no plans to support OpenFlow 1.3 at the moment. The aim of the initial project was an educational journey into developing OpenFlow applications, and the goals of the project have been met. The goal of seeding this project is to encourage the development community to build other SDN OpenFlow applications.
What other switches have you tested this with, aside from the NEC switch?
What kind of switches do you need for this to work?
Pearce: Any OpenFlow 1.0-capable switch should work with the tapping app.
Some switches do not support the header rewrite capabilities of OpenFlow 1.0, so the header rewrite used by the port chain object would not be supported, but all the other functions should be ok.
How hard would it be to port this application to other controllers?
Pearce: It should be quite easy to port to other controllers. There is only a handful of places where the tapping app uses methods on the OpenDaylight API. Prior to doing a port, we would suggest inserting a controller abstraction layer (CAL) and mapping the functions in each controller to our own northbound API.
Is SDN a new way of networking?
Pearce: SDN is a new way to configure, manage and monitor the network infrastructure. SDN does not always change the protocols used by the switches and other devices, but it does allow the network infrastructure to be reconfigured programmatically, usually from a central location. Most SDN implementations also separate out the control plane from the data-plane on the device, choosing to run the control logic off-device, in a central location, on standard off-the-shelf x86 servers.
Will it make the network more secure, or improve performance — or will centralized control make the network more vulnerable to attacks?
Pearce: The simple answer is that SDN won’t make the network more or less secure or improve the performance of packet forwarding in the network.
A centralized controller provides a new attack surface that could be subject to denial-of-service attacks or other vulnerabilities. For example, it is very easy to overwhelm the controller by sending packets to the switch that trigger the PACKET_IN message. Any deployment that plans to include SDN will need to consider the security architecture and take steps to mitigate threats.
Was the decision to move the application as a OSGi bundle more of a learning experience or does it have any actual advantages over an independent Java App?
Pearce: We thought this would be a better learning experience since OSGi is harder to use than the OpenDaylight northbound APIs. By running inside OSGi we have direct access to all the internal APIs and objects that OpenDaylight provides. We haven’t run any performance tests but it feels like running inside would provide better overall performance than running as a separate application connecting via the northbound APIs.
Will the source code be available at the end of the webinar?
Pearce: The source code is currently available at the ONF’s GitHub: https://github.com/OpenNetworkingFoundation.
Is the top-of-rack switch (ToR), or the aggregation switch, OpenFlow-enabled?
Pearce: Only the tap aggregation switch needs to support OpenFlow. The other ToR switch in our setup is using the port mirroring/spanning function, common in many commercial switches, to copy traffic from input ports to output ports. Hypothetically, this is probably going to be the real-world approach to tap live production traffic, because the ToR switches in an operator’s data center are likely not to support OpenFlow initially. But it would be an interesting use-case to use all OpenFlow switches to avoid the need to configure the port mirroring separately. That way a network admin could use a series of switches with OpenFlow table entries to get traffic to the tap aggregation switch using a single management interface. The port mirroring function typically has a proprietary interface to configure, such as a CLI or management UI.
Can you elaborate on the SwitchEntry object and how it helps in integrating a native app with OpenDaylight?
Pearce: We wanted to limit the extent to which the OpenDaylight objects were used in the application, and specifically didn’t want web-UI APIs to expose any of the OpenDaylight objects. This will help if we port to other controllers or support OpenFlow 1.3 in the future. Also, the SwitchEntry has additional fields that the user enters into the web UI when they associate the SwitchEntry with the OPFSwitch object.
Andy said they had discovered that the OpenDaylight controller was not documented well. Was there any effort to improve on this documentation?
Pearce: The OpenDaylight documentation is voluminous, but it documents each method in the API with a brief overview. What seem to be missing are tutorials for the common use cases that developers need to use.
We didn’t make a contribution to the OpenDaylight documentation as part of this project. However, we have discussed the documentation with the OpenDaylight Project and Linux Foundation members leading and working on OpenDaylight. They have been very open to hearing our suggestions about ways to make it easier for new developers to get started with OpenDaylight.
Any commentary on performance limitations of the amount of traffic that can be pushed through the tap? For example, a gigabit switch — can the tap support a full gigabit on the tap in that situation?
Pearce: With the NEC switch we haven’t detected any drops through the tap interfaces. However, theoretically drops can occur in the system due to several factors, including the OpenFlow switch implementation (for example, if the table entries aren’t held in fast path or the data performance of the switch is poor), the port mirror/spanning setup or performance limitations in the monitoring device/software attached to the capture port. If traffic from many input ports is feeding one output port (either in port mirroring or OpenFlow tapping), drops are likely to occur when the sum of traffic from input ports exceeds the physical transmit limit of the capture port. This input traffic sum can be exacerbated by propagating both transmit and receive traffic to a single output port. The drop issues can be alleviated by using the tapping application to filter only traffic of interest or by allocating more output ports as more input ports are included.