Last week I wrote about how the term “network TAP” is being misused in the SDN world. I explained how engineers might combine TAPs, NPBs, and SDN in a solution, using the joint IBM and VSS Monitoring “ConvergedMonitoring Fabric” as an example. And, in the last week, the leading SDN proponent announced a "TAP"--that is, an automated SPAN configuration tool that works with OpenFlow switches. It's an interesting announcement, which you can read about here: http://www.sdncentral.com/news/onf-debuts-network-tapping-hands-on-openflow-education/2014/03/. The announcement was made at the Open Networking Summit, the annual meeting of the Open Networking Foundation (ONF). (http://www.opennetsummit.org/)
ONF, which has been led by Dan Pitt since 2011, and which
some say has been driven by Nick McKeown from behind the curtains at Stanford,
is moving from shepherding the OpenFlow specification to delivering an open-source
project. (https://www.opennetworking.org/)
This event is worth noting because their fist SDN application is an “aggregation
tap” that works with an OpenFlow controller and OpenFlow switches. This is
quite a development for the ONF, which had spurned open source in the past and
left white space in the SDN arena for single vendor driven projects (like the
languishing Project Floodlight) and multi-vendor projects like Open Daylight
(ODL). (http://www.opendaylight.org/)
But it's not a TAP. This application requires tapping and TAPs to access
traffic. An OpenFlow switch, alone, can't get traffic from the production
network, and spanning ports directly from a production OpenFlow switch
encounters precisely the same issues as traditional attempts at using SPAN.
Dan Pitt, speaking for the ONF, asserts that the project is
merely an educational tool and that the open-source project, called “SampleTap,”
is a “non-invasive, experimental project.” That sounds very much like the
initial positioning for some SDN applications from embattled SDN startups,
which touted their own "tapping" SDN application as “your first
production SDN application.” The passive nature of tapping traffic and then
aggregating that tapped traffic does make the use case a safe starting point
for SDN. TAPs don't perturb the network. Combining TAPs with NPBs delivers
visibility into network data. For simple use cases, such as educational and lab
deployments, this open-source SDN application might provide a starting point
for software engineers needing to learning about the network or networking
engineers who are investigating SDN. SDN code alone, however, fails to provide
visibility and fails to improve security on large scale networks. SDN
applications alone, open-source or commercialized, do not meet those customer
needs because:
- Tools must be optimized. Switches can’t do this. They are limited to link aggregation, and very few production OpenFlow switches even support LAG.
- Traffic must be groomed. Current switches cannot re-write packets. They cannot support port and time stamping. They can only support basic aggregation and filtering.
- Monitoring fabric = hardware-accelerated meshed forwarding system. OpenFlow cannot do this today. NPBs and the vMesh architecture do this today.
- Initial tapping is required. No SDN offering supports a complete solution from TAPs to passive NPB to active use cases.
- Latency of white-box & commodity silicon switches is unacceptable for many applications.
SDN Apps alone are incomplete and must rely on NPBs and
TAPs. This sample application remains an intriguing development. This application
runs atop the Open Daylight SDN Controller, the same platform as the converged
monitoring fabric from VSS Monitoring and IBM. In a demo of the application, which is
based on Java and HTML5, a multi-switch system that supports aggregation and
OpenFlow filters was shown. Very basic unidirectional service insertion , a basic
approach to augmenting switch functionality with functions available only on
remote systems was also shown. This service insertion approaches show the
pre-cursor to tool chaining and service chaining, which have been something of
a holy grail in networking. The idea of “insertion” and “chaining” goes all the
way back to Cisco’s venerable Service Insertion Architecture and Juniper’s
“service chaining vision,” announced in 2013 with meager results thereafter.
Using complex routing configurations or overloading ancient protocols such as
WCCP in pursuit of chaining has been a bugaboo that led to many a network
outage over the year, so chaining is an important concept in networks.
Robust service chaining can actually be delivered today—and
is deployed in many large-scale networks today. In monitoring networks, the
chaining of performance tools and passive IDS systems utilizes VSS Monitoring’s
vBrokers. In active security deployments, service chaining for production
traffic uses VSS vProtector, which was designed to provide simple,
fail-safe service chaining. Today, to deliver functionality that can be
demonstrated in an educational application, such as SampleTap from ONF, network
engineers need commercial systems.
As such applications evolve from OpenFlow 1.0 to the more
recent and far more robust OpenFlow 1.3 standard, projects such as this sample
application represent a new tool for investigating SDN in a well-known use
case. This application can also help us clarify the differences between TAPs,
NPBs, and SDN aggregation applications, and it might just foreshadow a method
for combining SDN systems with NPBs. In discussions about the sample
application, Dan Pitt has assured his listeners that there are no plans to turn
SampleTap into a product. His goal is advancing OpenFlow, not delivering
products, he said.
