OpenFlow And Mikrotik

As of RouterOS V6 RC8, Mikrotik has integrated an Alpha version of OpenFlow. The first thing I said was “Oh neat…what is OpenFlow?”

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switches, routers and wireless access points – and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being implemented by major vendors, with OpenFlow-enabled switches now commercially available.

What does this really mean, though?

You start with an OF switch and a controller. The OF switch is a switch/router/access point that runs the OF client. Most switches have a “flow table” built from TCAM. This flow table determines which traffic moves where.

OpenFlow(OF) is meant to be a means of testing new routing or forwarding methods to build these flow tables. It is designed to allow for layer 3 or layer 2 forwarding based on: port, MAC, VLAN, TCP header, or IP header.

The way it accomplishes this is to establish a secure SSH tunnel between the OF switch and the controller. The controller will run whatever this new routeing process is. When a new flow starts, it sends the first packets to the controller. The controller then builds an entry into the flow table to handle the remainder of this connection. This is very reminiscent of Cisco’s original Netflow. Netflow was often referred to as “route once, switch many.” You are probably thinking, “how many connections can this controller sustain?” Their documentation says that a standard PC running controller software should be able to support 10,000 new flows per second. This would be “enough for a large campus network.” This is definitely some heavy lifting.

They also have the ability to segregate the OF flow table from that of the standard switch. The idea is you can choose a handful of ports on a device and have them participate in the OF test. Your controller will then update all of the OF switches in the chain with the new flow information. Since this is a separate flow table the device will continue to process all other traffic based on the standard flow table.

I’ve read that in addition to this you can also have all traffic meeting given criteria to flow to the controller; this would be good for captures. You could also in theory use this to move all traffic sourced from certain ports to flow through an IPS or transparent proxy.

One of the examples I read is if you come up with your own super cool version of OSPF, then you can test it on live traffic without affecting the bulk of your users. I really like the idea of being able to write complex algorithms on my own…:) I can then have that push through the entirety of my Mikrotik domain.

So long as you can maintain the SSH connectivity to the controller you can write your own proprietary mesh algorithm and have the MTKs use it. You could write your own algorithm that monitors all of your ISP interfaces via SNMP and adjust routing on the fly according to congestion…really the sky is the limit at this point.

Right now there are really only two commands in the Mikrotik:

1
2
3
4
5

#Specify the OF switch and controller address
/openflow add name=ofswitch1 controllers=1.1.1.1
 
#Add ports to the OF switch
/openflow port add switch=ofswitch1 interface=ether2

BTW, MTK says that since it is so early in the dev state that it is NOT ready for production 😉

There is a list of OF controllers here. There is also a slicer there…more or less a load balancer for the controllers.

Anyone interested in running my proprietary protocol?