What’s new in 6.0rc8 (2013-Feb-04 13:25):

*) ppp,pppoe,pptp,l2tp,sstp – only 2 change mss mangle rules are created for all ppp interfaces;
*) wireless – fixed AES encryption speed issues (upgrade suggested);
*) dhcpv6 server – handle info requests;
*) webfig – compressed all html resource files, speeds up opening of webfig page;
*) console – reduced width of address column in ‘/user print’;
*) simple queues requires target arg to be specified when adding;
*) do not count packets for unknown protocols as rx_dropped;
*) snmp – provide POE info;
*) improved cpu usage reporting on CCR boards;
*) improved interface reading performance;
*) changed CLI interface order – first are ethernets, second wireless, third everything else.
Within group interfaces are ordered by name;
*) interfaces are deleted much faster, could be bottleneck on systems with many ppp sessions;
*) pptp,l2tp,6to4 tunnel encapsulation/decapsulation now resets packet marks to
have consistent behavior across tunnels;
*) fix simple queue interface matching when doing encapsulation in some tunnel,
could result in double accounted packets;
*) ip/ipv6 firewall has all-ether,all-wireless,all-vlan,all-ppp interface matchers
*) queue limits could be inaccurate for large limits (100M or more);

CAVEAT:

*) bgp peer tcp-md5-key is not supported on CCR (to be fixed in next release);

I don’t normally post up RC info, but since all of my CCR peeps are going to want it, here you gooooooo.

Odd, they left off the openflow info. Perhaps it was only available for the pre-release crowd(this is the part where I pretend to be Superior). *EDIT* They’ve now added it back 🙂

What’s new in 5.23 (2013-Jan-29 14:07):

*) lcd – changed gamma, which gives greater contrast
*) fix reboot when running on third party hypervisors;
*) ppp client – fixed possible loss of configuration after reboot for some modems;
*) fixed wifi led order on “SXT Lite5”;
*) wireless – improved nv2; Sounds like something…only what could it be…hehe

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?