< back to overview

Designing SampleTap

Apr 24, 2014
Sue Kim - gu
Sue Kim - gu About the author

The SampleTap blog series continues with an explanation of the ONF application, developed by Wiretap Labs’ Andy Pearce.

As I mentioned in my last blog post, Wiretap Labs wanted to learn what it would take to develop an application for ONF leveraging OpenFlow, so we set out to build a native, Java-based app on OpenDaylight and captured our experience to share with the community. It is meant to serve as an educational resource for programmers, allowing them to gain experience with OpenFlow® and to test the protocol within their networks. In this post, I will give an overview of the basic functionality of what we created – a network tapping aggregation app called “SampleTap.”

An Overview of SampleTap
ONF SampleTap is a network monitoring tool that uses OpenFlow-enabled switches to create virtual taps anywhere in the network. While SampleTap is not meant to be a highly-scalable or robust tapping app for enterprise-wide deployments, the design should allow it to be used within most environments for simple monitoring and educational purposes.

SampleTap allows network administrators to:

1. Define fairly complex matching criteria for traffic as it flows through a switch.

2. Specify, via a policy, how matching traffic should be redirected to one or more network monitoring, performance monitoring, or security devices (by defining which switch and port those devices use to connect to the network).

Additionally, an administrator can add port chains used to transform data before it is sent to the capture devices, which can help with performing truncation or decryption of network traffic.

The Web-based user interface of this application has been designed to allow the administrator to configure objects once and reuse them across multiple tapping policies. Once configured, the match rules contained within the tap policy set can be quickly applied to a large number of switches and ports.

Modes of Operation
In its original design, the application supports two different deployment modes – Inline (Normal) Mode and Tap-Aggregation Mode:

  • Inline (Normal) Mode: The OpenFlow-enabled switch runs normally, processing Layer 2/Layer 3 traffic, with tapping rules running as an exception. This mode allows the switch to send only specific flows to the capture devices. The below figure illustrates a deployment using Inline Mode.

[caption id="attachment_1161" align="aligncenter" width="300"]Deployment Using Inline Mode Deployment Using Inline Mode[/caption]

  • Tap-Aggregation Mode: The OpenFlow-enabled switch is used like a Network Packet Broker (NPB) that pulls together multiple tap interfaces from different switches. In this mode, traffic from all flows that match the specified criteria can be directed to the capture devices for processing or analysis. The figure below illustrates a deployment using Tap-Aggregation Mode.

[caption id="attachment_1162" align="aligncenter" width="300"]Deployment Using Tap-Aggregation Mode Deployment Using Tap-Aggregation Mode[/caption]

The SampleTap application can be deployed with existing OpenFlow-enabled switches by configuring the app to use Inline Mode or Tap-Aggregation Mode. In Inline Mode, the switch performs the normal Layer 2 and Layer 3 packet forwarding functions and only taps the flows that match the criteria specified by the user. In Tap-Aggregation Mode, the switch becomes an aggregation pseudo-replacement for NPBs.

What Needs to Happen with the Controller?
After further review of the OpenFlow® 1.0 specification and discussions with data center operators and switch and chipset vendors, we concluded that focusing primarily on Tap-Aggregation Mode would be better aligned with real-world use cases and supported by the majority of switches. From this point on, I will focus on this mode.

In Tap-Aggregation Mode, the OpenFlow® rule set includes:

1. A number of rules implementing specific instructions to match relevant flows. For network traffic flows we wish to capture, we need an OpenFlow® rule with the ACTION set to OUTPUT that will send traffic to one of the switch ports connected to capture devices.

2. A fall-through (low-priority) “catchall” rule that directs the switch to discard any packets that are not matched by higher priority rules. This prevents the switch from overwhelming the Controller with a PACKET_IN message for each packet associated with an unrecognized network traffic flow.

3. If port chains are implemented, a set of rules that direct flows out of a specific port and receive processed flows back into the tap-aggregation switch for subsequent distribution to the capture devices.

The Value of OpenFlow
SampleTap is useful for simple, everyday troubleshooting and analysis. While an OpenFlow® switch cannot replace all of the existing functions that NPBs provide, users can implement tapping via a simple, Web-based user interface without the need to physically configure taps, span ports, and recording or inspection devices. As a result, this OpenFlow-based tapping application should make identifying and capturing highly specific flows within the network much more convenient and cost-effective.

Next Time…
In my next post, I will describe the detailed process of creating the ONF SampleTap app.

- 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.

Share this post:
Sue Kim - gu