In the third blog post of the SampleTap series, Andy Pearce addresses the network tapping application’s development process.
In the first two parts of this four-part blog series, we described our planning as we set out to develop a native, Java-based application that uses OpenFlow, and the lessons we learned along the way. In my previous two posts, I offered an introduction to the project and an overview of the ONF SampleTap application design. This post will discuss the details of how we developed the tapping aggregation app.
Our App Requirements
When building an application, it’s important to have a clear understanding of what you are trying to accomplish. As we started designing the ONF tapping aggregation app, the criteria we wanted to meet included:
- Making it as easy as possible for others to use and extend the application.
- Promoting portability by limiting dependencies on the underlying controller functions, allowing integration with other controllers and northbound APIs, and using a portable persistence layer for storing configuration data and statistics.
- Providing a flexible logging mechanism with the ability to send messages to the console, database, separate log files, or a controller logging system.
- Building an app with a clean and simple architecture and well-defined abstraction boundaries between the controller, persistence layer, and application logic.
We also wanted to demonstrate only the most basic feature set. The ONF SampleTap application was therefore designed to have the following functionality:
- Providing simple match criteria on incoming flows from the Top-of-Rack (ToR) or access switches.
- Supporting external processing of matching flows via port chains, allowing traffic that is matched to be run through chains of external devices that can perform more advanced functions like decryption or truncation.
- Allowing multiple capture devices and header rewrites (assuming switch support), prior to sending the captured packets from matched flows into the capture devices.
- Showing basic statistics as well as logging information for troubleshooting and debugging.
Getting Started
To ensure we could deliver a compelling and intuitive demo to help others understand the capabilities of the application, we decided we needed a Web-based user interface (UI) to control SampleTap. I don’t consider myself a UI developer, so for purposes of efficiency, we brought in a developer who had experience with Javascript, HTML 5, and Ruby to build the Web UI components.
We started by writing a basic specification document that extrapolated our high-level requirements into more detailed specifications. We also included some Balsamiq mock-ups, showing the basic UI screen shots and descriptions of a few workflows to illustrate the common use cases. We then completed the following development process steps to design and implement the tapping application:
1. Defined the user-facing requirements in a text document, supported by descriptions of the common workflows and Balsamiq mock-ups of the major screens in the Web UI.
2. Researched the capabilities of OpenFlow® and built the sample applications provided.
3. Specified the key technology components (Web UI, Web server, MongoDB, etc.) and documented the system block diagram.
4. Translated the user requirements into a domain object model and documented it using a UML static-structure diagram.
5. Worked with the Web UI developer to define and document the Web UI APIs and the supporting mid-tier functionality.
6. Implemented and tested the mid-tier logic and UI-facing APIs, then integrated and tested the Web UI with the mid-tier and backend database.
7. Converted the application to an OSGi bundle and integrated with OpenDaylight.
8. Subscribed to the required OpenDaylight services and tested using switch connect/disconnect events.
9. Implemented the application logic needed to traverse the objects stored in the database and generated the required flow rules based on the user-specified configuration.
10. Integrated and tested end-to-end, fixing bugs and adding the remaining functionality.
11. Added log viewer and statistics APIs to complete the Web UI views.
Sample Use Case
When we built the network tapping app, we had a primary use case in mind. We envisioned an administrator looking to apply tap-aggregation to ToR or access switches that handle normal traffic through the network. This administrator could use a Web UI to configure the tap-aggregation switch to capture a subset of this traffic for further processing and analysis.
The workflow required to configure the application to support this use case would be as follows:
1. Configure the ToR switch to span the appropriate ports.
2. Configure the tap-aggregation switch to use OpenFlow® to connect to the server, where the tapping application and OpenDaylight controller would be running.
3. Use the Web UI to confirm that each switch has registered with OpenDaylight by checking for the presence of an OPF switch.
4. Bind the OpenFlow® switch object for each switch to a corresponding SwitchEntry object, and set the mode to Tap-Aggregation Mode.
5. Use the Web UI to build one or more MatchCriteria, specifying the switch ports and fields in the L2 and L3 packet headers that describe the network traffic flows that the user wishes to capture. Optionally, also check the box to enable flow rules for reflexive network traffic flows.
6. Use the Web UI to define one or more CaptureDevices and select the SwitchEntry and port number on the switch where the device is connected.
7. Create a TapPolicy object that associates the MatchCriteria with the one or more switches (defined by selecting the SwitchEntry objects and specifying the ingress traffic port for each), and with one or more CaptureDevices to receive the traffic.
Note that to support multiple switches, switch link chains need to be created to identify the links between switches and define how flows should be forwarded across them to direct tapped flows to the capture devices, when necessary.
Future Enhancements
We can imagine a number of enhancements that might be added to the tapping application later. For example, in the future, the app could be extended to support high availability and improved scalability. We could also add usability features that would make it easier and more convenient to define the set of flows to tap and capture, such as predefining common protocol numbers, or Ethernet header types.
The application demonstration code is available from ONF’s GitHub, and provided under an Apache 2.0 license, so all developers are welcome to download and add to it.
Next Time…
In my next post, I will talk in detail about what we learned regarding integration with OpenDaylight and OSGi.
- Andy Pearce, System Architect, Wiretap Labs
Andy Pearce has spent his last 20 years as a software developer and system architect. Most of his career has been spent building high-performance, real-time and embedded systems using communications and networking technology. Andy’s development work has been primarily focused on using C and C++ with a heavy emphasis on STL.
Andy is currently the lead developer and architect for Wiretap Labs, which provides custom development and system architecture services for enterprise customers, specializing in SDN, NFV, cloud-based solutions and network security. Andy spends his days working with clients to help architect cloud and SDN-based solutions.
