The document evaluates OpenFlow implementation in RouterOS 6.6 on an RB750GL router. Testing showed that while the control plane functions, forwarding does not work properly. Packet-in messages are not generated and flows installed by the controller are not matched. This is due to buffers being set to zero, preventing packet-in messages. The router also cannot replace or rewrite packet headers as required. The current implementation is experimental and not production ready.

1. Evaluation of OpenFlow in RB750GL
- RouterOS 6.6 -
2013.11.19
@ttsubo

2. Motivation
I want to get the OpenFlow s lab in minimum cost .
So, I am so happy what if it works under the experimental version .
Currently RouterOS implements OpenFlow version 1.0.0 required
features. Support for newer versions, optional features and switching
hardware acceleration are to be added. Current implementation should
be considered experimental - NOT production ready and is available
for evaluation purposes. Please contact support with feature requests
and bug reports.
OpenFlow support is available as standalone openflow package.
OpenFlow feature overrides regular packet processing functionality packets that are received on interfaces that are OpenFlow switch ports,
will not pass through the regular networking stack unless OpenFlow
controller sets up flows that enable this. Due to this care must be taken
to not disable access to the device when configuring OpenFlow.
Currently only unencrypted TCP is available as the communications
channel between RouterOS OpenFlow switch and controller.
http://wiki.mikrotik.com/wiki/Manual:OpenFlow
2

3. Test Scenario1: IP Routing in OpenFlow
3

4. Test Scenario1: IP Routing in OpenFlow
- ICMP Echo Request from PC-A to PC-B
- ICMP Echo Reply from PC-B to PC-A
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Request
ARP Reply
ICMP_Echo Request
192.168.1.1
Packet-in
Packet-out
Packet-in
Packet-out
Drop!!
ARP Request
ARP Reply
FlowMod
ICMP_Echo Request
ICMP (Echo Reply
ICMP_Echo Request
ICMP (Echo Reply
4

5. Test Result : No good !!
The OFS doesn t send ARP Packets to OFC
using packet-in messages .
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Request
ARP Reply
ICMP_Echo Request
192.168.1.1
Packet-in
Packet-out
Packet-in
Packet-out
Drop!!
ARP Request
ARP Reply
FlowMod
ICMP_Echo Request
ICMP (Echo Reply
ICMP_Echo Request
ICMP (Echo Reply
5

6. Investigation of the cause
When the secure channel has established, I ve checked
Features Reply packet as below .
OFS
OFC
Secure
Channel
It looks like Max packets buffered
sets zero value .
Hello
Hello
Features Request
Features Reply
Set Config
Echo Request
Echo Reply
6

7. Investigation of the cause
Because of Max packets buffered: zero , the OFS doesn t
send Packets to OFC using packt-in messages .
/* Switch features. */
struct ofp_switch_features {
struct ofp_header header;
};
OpenFlow Switch Specification Version 1.3.2
7.3 Controller-to-Switch Messages
uint64_t datapath_id;
uint32_t n_buffers;
uint8_t n_tables;
uint8_t auxiliary_id;
uint8_t pad[2];
/* Datapath unique ID. The lower 48-bits are for
a MAC address, while the upper 16-bits are
implementer-defined. */
/* Max packets buffered at once. */
/* Number of tables supported by datapath. */
/* Identify auxiliary connections */
/* Align to 64-bits. */
/* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */
uint32_t reserved;
};
OFP_ASSERT(sizeof(struct ofp_switch_features) == 32);
The datapath_id field uniquely identifies a datapath. The lower 48 bits are intended for the switch MAC address, while the
top 16 bits are up to the implementer. An example use of the top 16 bits would be a VLAN ID to distinguish multiple virtual
switch instances on a single physical switch. This field should be treated as an opaque bit string by controllers.
The n_buffers field specifies the maximum number of packets the switch can buffer
when sending packets to the controller using packet-in messages (see 6.1.2).
Reference : Max packets buffered
7

8. Test Scenario2: IP Routing in OpenFlow
without Packet-in
8

9. Test Scenario2: IP Routing in OpenFlow w/o Packet-in
I ve rebuilt Test Scenario1 without Packet-in as below .
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Request
192.168.1.1
Packet-in
Packet-out
PC-A and PC-B has already done
the sequence ARP resolve .
ARP Reply
ICMP_Echo Request
ARP Reply
Packet-in
Packet-out
Packet-out
Packet-out
Drop!!
ARP Request
ARP Reply
ARP Reply
FlowMod
ICMP_Echo Request
ICMP (Echo Reply
ICMP_Echo Request
ICMP (Echo Reply
9

10. Test Result : No good !!
PC-A hasn t received ICMP_Echo_Reply .
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Reply
192.168.1.1
Packet-out
Packet-out
ARP Reply
FlowMod
ICMP_Echo Request
ICMP (Echo Reply
ICMP_Echo Request
ICMP (Echo Reply
No received !!
10

11. Investigation of the cause
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Reply
192.168.1.1
Packet-out
Packet-out
ARP Reply
FlowMod
ICMP_Echo Request
[admin@MikroTik] > openflow flow print detail
Flags: I - inactive
0 switch=oflow1 version=1
match="inport:1 dlsrc:7C:C3:A1:87:8F:65 dldst:00:00:00:00:00:01 dltype:0x800
nwdst:192.168.1.1/32"
actions="set_dl_src:00:00:00:00:00:02, set_dl_dst:00:1A:80:0A:9E:D4, output:2"
ICMP_Echo Request
OFC has set to
the FlowMod
in properly
info="priority 255, idletimeout 0, hardtimeout 0, cookie 0, removenotify 1"
!
1 switch=oflow1 version=1
match="inport:2 dlsrc:00:1A:80:0A:9E:D4 dldst:00:00:00:00:00:02 dltype:0x800
nwdst:192.168.0.1/32"
actions="set_dl_src:00:00:00:00:00:01, set_dl_dst:7C:C3:A1:87:8F:65, output:1"
info="priority 255, idletimeout 0, hardtimeout 0, cookie 0, removenotify 1"
11

12. Investigation of the cause
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
192.168.1.1
Packet-out
ARP Reply
Packet-out
ARP Reply
FlowMod
ICMP_Echo Request
ICMP_Echo Request
A Flow statistic hasn t counted up .
So, the FlowEntry doesn t work in properly .
[admin@MikroTik] > openflow flow print stats
Flags: I - inactive
# SWITCH MATCH
BYTES
0 oflow1
1 oflow1
0
0
inpor...
inpor...
PACKETS DURATION
0 3m38s830ms
0 3m38s830ms
12

13. Investigation of the cause
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Reply
192.168.1.1
Packet-out
Packet-out
ARP Reply
FlowMod
ICMP_Echo Request
ICMP_Echo Request
When PC-B has received
ICMP_Echo_Request from PC-A,
PC-B hasn t sended
ICMP_Echo_Reply
13

14. Investigation of the cause
This packet is ICMP_Echo_Request
in PC-A
192.168.0.1
（7C:C3:A1:87:8F:65）
OFS
PC-A
192.168.0.10
（00:00:00:00:00:01）
192.168.1.1
（00:1A:80:0A:9E:D4）
The OFS doesn t
replace mac_address
fields in spite of
storing FlowTable .
PC-B
ICMP_Echo Request
14

15. Investigation of the cause
When the secure channel has established, I ve checked
Features Reply packet as below, again .
OFS
OFC
Secure
Channel
OFS in RouterBOARD can t
replace L2/L3 header field .
Hello
Hello
Features Request
Features Reply
Set Config
Echo Request
Echo Reply
15

16. Conclusion:
The latest OpenFlow code under the experimental version
doesn t work in properly as below in RB750GL.
I m looking forward to releasing the product version .
OFC
FlowMod
: it works
SecureChannel
: it works
Packet-out
: it works
Packet-in
: it doesn t work
PC-A
PC-B
Flow Table
OFS
Forwarding
: it doesn t work
16

17. referense : OpenFlow in Open-WRT
It works in Test Scenario1: IP Routing in OpenFlow !!
OFS
PC-A
OFC
PC-B
Secure
Channel
192.168.0.1
ARP Request
ARP Reply
ICMP_Echo Request
192.168.1.1
Packet-in
Packet-out
Packet-in
Packet-out
Drop!!
ARP Request
ARP Reply
FlowMod
ICMP_Echo Request
ICMP (Echo Reply
ICMP_Echo Request
ICMP (Echo Reply
17