Erlang Solutions and InfoBlox Release an OpenFlow 1.2 Switch

Kudos to the folks at Erland Solutions and InfoBlox.  Today, they released an OpenFlow 1.2 compliant switch, code-named LINC, which as you might have guessed is written in Erlang.  The switch is offered under a the commercially friendly Apache 2.0 just like the Floodlight OpenFlow controller.  Erlang Solutions plans to offer professional services around the LINC switch and OpenFlow in general, including set-up, configuration, support and testing.

LINC is available at Check out the video of it in action.

As a member of the Floodlight team, I’m really excited to see future versions of OpenFlow begin appear in switch designs and we are also hard at work in bringing Floodlight (which currently supports OpenFlow 1.0) up to speed with these designs as well.

– Mike Cohen

An OpenFlow Programmable Patch Panel

Kudos to Dan Hersey, a systems engineer at Big Switch Networks, who recently set up a programmable patch panel using OpenFlow.  Its a creative and very useful way of taking advantage of open source tools like Floodlight and Indigo. He even went all the way and wrote an IPhone app that can push static flows to help manage the patch panel he built.  Awesome! Dan’s Article follows below.

When I started exploring the OpenFlow protocol I was struck by how fundamentally it could change networking.  OpenFlow truly provides a clean slate to correct the network mess we have created over the last 20 years. Solutions such as network virtualization, lawful intercept, network service insertion and other super cool (and highly desirable) concepts based on OpenFlow have garnered the most press but there is limitless possibilities.

Continue reading »

Snapshot of the 2012 Interop Labs OpenFlow booth preparations

Next week is Interop where OpenFlow will be displayed in various vendor booths and, similar to last year, in it’s own “Interop Labs” OpenFlow booth.

I was Las Vegas this week helping setup and wanted to share this snapshot of the progress.  Last year’s Interop Labs booth really put OpenFlow on the map and this year is shaping up to be even better!

Hope to see you there next week!

Continue reading »

Google, SDN, and Open Source

Last week, Google made a huge announcement in the world of software-defined networking.  They had in fact built their own OpenFlow-based SDN (including their own custom networking gear) and were using it to manage all of their production WAN traffic.  Google’s SDN enabled it to implement a global bandwidth management and traffic engineering system, saving money on bandwidth and hardware.  

For a company very secretive of its infrastructure, Google took a major step in support of the growing OpenFlow and SDN ecosystems.  They immediately dispelled any myths and concerns about the maturity of SDN  and made it clear that real, reliable software-defined networks were managing production traffic in one of the most complex infrastructure environments in the world.  This is a huge boost to the SDN ecosystem. Continue reading »

Indigo 2012.03.19 Released!

The Indigo team is pleased to announce release 2012.03.19.

For those not familiar with Indigo, its an open source project that supports OpenFlow on a range of physical switches (including Pronto and Netgear).  Indigo firmware is actively used in many campus deployments (at Stanford and several other schools), in at least one OpenFlow startup, a 20-switch conference network deployment and a 32-switch data center deployment.

If you want to get your hands dirty with OpenFlow, Indigo on a platform like Pronto is a great way to do it.  And of course, its well tested with the Floodlight controller. Continue reading »

Understanding Openflow controller statistics

Network Monitoring has been an integral part of operating a network. It not only provides the visibility into how well the network performs, but also is an important tool when it comes to troubleshoot problems. Given the distributed nature of switching or routing devices in the network, a typical network monitoring tool usually queries a set of devices via some network management protocol, such as SNMP, and correlates results into reports or graphs. Even though SNMP is standardized, many vendors provide extension to the standard MIBs, which forced the management tools to be vendor aware and sometimes even version aware. For example, each router vendor has its own MIBS for MPLS and MPLS-based tunnels and VPNs.

Openflow provides a centralized controller architecture that can consolidate many network states at a logical central server, which is called Openflow controller. The controller is not only the brain for the network, but also a software platform for other network applications. Network monitoring applications will be able to leverage controller’s global view of the network and provide visibility into the connectivities, throughputs, and flows at the data-path. The same application can also be standalone if it chooses, but still have the power to query network states and statistics via controller’s north-bound interfaces. The standardization of controller’s north bound interface is currently under consideration.
The floodlight controller has a counterStore module that support counter-like statistics. The controller already collects a set of openflow statistics, which are available through its REST interface. Currently, the controller collects overall counts of OFPacketIn, OFPacketOut, and OFFlowmod and separate counts by switches and ports. The OFPacketIn counters are further classifies into separate broadcast, multicast, and unicast counters and different Layer 3 and L4 protocol counters to give the visibility of the types of flows in the network. It also keeps track of the number of active flows per switch. All counters are available via controller’s REST interface.
For example,
  • an OFPacketIn of a particular switch can be retrieved with “http://<controllerIp>:8080/wm/core/counter/<switchdpid>/OFPacketIn/json”.  The output is a json dictionary object:
               “<switchdpid>”: {
                    “Fri Mar 02 19:38:13 UTC 2012”: 128
  • an OFPacketIn for L3 IPv4 counts: “http://<controllerIp>:8080/wm/core/counter/<switchdpid>/OFPacketIn__L3_IPv4/json”.
          The output is a json dictionary object:
               “<switchdpid>”: {
                    “Fri Mar 02 19:38:13 UTC 2012”: 102
There are many more important statistics that can be collected and useful in troubleshooting or providing better visibility into the health of the network. Please let us know or simple upload an implementation for your favorite stats.
— Kanzhe Jiang

Mirage offers an OCaml-based OpenFlow implementation

The Mirage team are very pleased to announce a new experimental OpenFlow implementation in 100% OCaml. Designed as part of the Mirage platform, this release provides both controller and switch support as libraries.

Mirage is a cloud programming platform that lets you build your OCaml application as a POSIX binary, a node.js module or a self-contained, single-purpose Xen virtual machines. The controller implementation means your application can directly control the network, acting as a full OpenFlow controller. The switch provides a software OpenFlow switch implementation, an ideal basis for experimentation and extension. Both switch and controller are high-performance, comparable with Open vSwitch and NOX respectively. For more details, see and let us know what you make of it!


Richard Mortier

Mirage Operating System

Understanding OpenFlow: Packet-In is a Page Fault

One of the most fundamental and often controversial features of the OpenFlow protocol is the “packet-in”.  Recall from the specification that the OpenFlow controller pushes packet forwarding rules down to an OpenFlow device.  Each rule is of the form “if a packet’s header matches pattern X then apply policy list Y”.  When a packet arrives that matches an existing rule, the corresponding policy is applied, e.g., what interface to forward out, what QoS queue to apply, etc.  However, if a packet does not match any of the existing rules, OpenFlow’s default policy is to send a copy of that packet up to the controller.  This “packet sent to the controller” message is called, in OpenFlow-parlance, a “packet-in”.

Now, if you work with large networks (either operate them or sell to people who do), the concept of _intentionally_ sending packets to controller by default—and thus across the control plane—frankly probably has you horrified.  Data packets going on the control plane is a denial of service (DoS) waiting to happen and you’ve probably spent a good chunk of your career either debugging the resulting problems (“Why is my router’s CPU at 100%?  Aargh!”) or trying to ensure that this DoS can’t happen in the first place (“Sure IP multicast (or unsampled netflow, IPv6 options parsing, etc.) would be useful, but I disable it because I worry that it could cause instabilities”).  Yes, equipment manufacturers spend a lot of time trying to ensure that data packets get punted up to the control plane only when absolutely necessary (e.g., for routing protocol updates), but the harsh reality is that even hardened “carrier-grade” production equipment still occasionally falls victim to a control-plane DoS[1].  This is not because vendors are incompetent but rather because it’s inherently a very complex engineering game of wack-a-mole.  Each new feature might impose a different requirement on data-to-control plane interactions, and the sum of all features on the box have to result in a unified set of rules that decide which data packets can go to the control plane and how they are rate limited.  Being too conservative with these data-to-control-plane rules and rate-limits risks DoS on the control plane: routing processes become starved, CLIs hang, and networks can destabilize.   But on the other side, being too aggressive—that is blocking or rate limiting too much—can break features or have a negative impact on performance.

If the bad news is that the data-to-control-plane problem is well-known and hard, then the good news is that all of the same tools that vendors already apply to this problem are also available to OpenFlow controllers.  That is: an OpenFlow controller can block traffic, install rate limiters, or even change the default policy for an unmatched packet to drop it on the ground.  Depending on the applications loaded and the target network deployment, the OpenFlow controller will apply different drop rules, rate limits, and default policies.  For example, a Tier-1 service provider network will likely choose to only send routing updates (likely rate limited) to the controller and drop all unmatched traffic, where a security-sensitive enterprise network might choose to send as much unmatched traffic as possible to the controller for auditing and monitoring purposes.  The bottom line is that using OpenFlow does not fundamentally change this problem: all of the same dangers, solutions, and trade-offs exist.

Once you accept that packet-in—when used properly—is a safe and even necessary component to any functioning network, the real fun can start because packet-in is the networking equivalent of a virtual memory page fault.   While they add a degree of overhead that must be managed, Packet-in’s, like page faults, also enable all sorts of new functionality.   They make it possible to offer applications a clean programming interface, create hooks for sophisticated resource management, and even enable advanced capabilities like virtualization.

Obviously, one could talk about this analogy at length but I wanted to present it to the community to generate discussion and get people to step a little out of their comfort zone.  Does it work for you – feel free to chime in on the comments…

[1] From which, unfortunately, I can personally attest: some of my past network research work accidentally exposed holes in the vendor’s control-plane rate limiting policy, much to the unhappy surprise of more than one operator.


Free t-shirts for Floodlight developers!

We’ve gotten our first stock of Floodlight t-shirts in and I’d love to share them with folks developing applications on top of Floodlight (they are really nice microfiber!).  As I’m sure you know, Floodlight is our Apache-licensed OpenFlow controller platform.
There are just a few guidelines:
  • The “application” is up to you but it must be more interesting than a simple hello world-style app.  Some of the work done on Trema apps ( is probably a good guide here.  Be creative and think about some interesting ways to use OpenFlow.  We will be liberal on this front but if you have a question or need ideas, just ask.  
  • The application must be open source.  We will include it in the Floodlight repository as a code example if its not hosted somewhere else already.
  • The application can either be in Java using Floodlight’s event handlers or written to use the static flow pusher REST API in any language you choose.
The submission process is simple — just email the Floodlight admin list ( and let us know what you’ve built (or are in the process of building).   We’ll take a look and send you a free t-shirt!

Check out NodeFlow – a Node.js-based OpenFlow Controller

Last week, I officially announced the release of Floodlight, a Java-based OpenFlow controller, and as you might imagine, I’m always interested in new developments in the world of OpenFlow and Software-Defined Networking.  After all, projects that make SDN development easier and more accessible to a large pool of developers are essential to the emergence of an application ecosystem.


That’s why I wanted to mention NodeFlow, a Node.js-based OpenFlow controller.  Node is a fast, lightweight, and efficient server-side javascript platform based on Google’s V8 runtime and its gaining a lot of developer momentum.  While I haven’t spent a lot of time with NodeFlow (I’ve neither contributed to it nor talked with the author), it struck me as a great project and a great way to expand the community of SDN developers.

So, if you have a minute, check out NodeFlow!