Add a Flow with "Write-Action" Instruction via REST-API of HPE-SDN-Controller V 2.7.18

[Tobias-hab]

Hello,

I added some Flows via the REST API. There i can use the "apply_action" or the "meter"-Field in the Instruction. For example:

{

"flow":{

"priority":50100,

"table_id":100,

"match":[

{"eth_type": "ipv4"},

{"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},

{"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],

"instructions":[{"apply_actions":[{"output":"NORMAL"}]},

{"meter":1}]

}

}

With this Flow I can use one of my meters for the given Match. My Switches (HPE 2920) support OpenFlow 1.3.0. OpenFlow 1.3.0 supports the Write_action order and according to the documentation of the REST-API I can use the "write_action" order too. So I tried to add some information to an action-set of a given data paket:

{

"flow":{

"priority":50100,

"table_id":100,

"match":[

{"eth_type": "ipv4"},

{"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},

{"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],

"instructions":[{"write_actions":[{"output":"NORMAL"}]},

{"meter":1}]

}

}

But this doesn't work. I get this error message:

{
"error": "java.lang.IllegalArgumentException",
"message": "Failed to validate flowmod: {ofm:[V_1_3,FLOW_MOD,120,1717169],cmd=ADD,match={Match(V_1_3):[type=OXM,len=34],fields=ETH_TYPE,IPV4_SRC,IPV4_DST},...}"
}

Tanks to ShaunWackerly I know that I can use the debug mode on the given switch to gather further information. The debugger told me that the "Write-Action" instruction is not supportet for Flow Table 100.  So I tried other Flow-tables, even no Flow-table, but nothing helped me to solve this issue. Here the official switch debug output: 

0002:21:31:50.16 OPFL eOFNetTask:{ "error_code":"OFPBIC_UNSUP_INST","error_reaso
n":"Instruction 'write_actions' is not a supported instruction for table
100","process_time":"0.069 ms","command":"OFPFC_ADD","table_id":100,"

I hope someone can help me or tell me that the 2920 Switch with software release WB.16.04.0008 (latest release) is not able to use write-action.

Regards Tobias

[ShaunWackerly]

Hi Tobias,

The write-actions instruction is only supported in hardware on the latest HPE Aruba switches (2930, 3810, 5400R) when using custom-pipeline. The 2920 does not support the custom pipeline and therefore does not support write-actions in hardware.

The only option you'd have for write-actions support on 2920 would be to perform the write-actions in the software table (200). You'd need to insert one flow which copies traffic to the software table, and another flow which applies the write-actions to the packet.

Please let me know if I need to explain in more detail.

Shaun

[Tobias-hab]

Thanks for your answer.

My investigation in software- and hardware -tables told me that flow-table 100 ist a hardware flow-table and table 200 a software flow-table, as you already told me. I also read that only flow-table 100 supports meters. I also read a very detailed technical document (Performance Analysis of SDN Switches with Hardware and Software Flow Tables - by Piotr Pygielski, Marian Seliuchenko, Samuel Kounev and Mykhailo Klymash). Acording to thise document, the storage of a flow depends on the "rule insertion engine" and on the type of matchfield. Furthermore it says that the hardware table is based on TCAM. Flows that do not match with TCAM are stored in the software flow table (SDRAM) . Getting more into detail, I also found out that flows from an 2920 switch in the software flow-table supports only 2% of maximum throughput. According to the document the rule insertion engine can replace flows from the hardware flow-table with flows from the software flow table (only with OpenFlow Version 1.0 active). The mentioned document (PDF) can be found via any searchmachine. 

This whole information confuses me a little, because I can chose the flow table by myself when I create a flow. for example:

{

"flow":{

"priority":50100,

"table_id":100,

"match":[

{"eth_type": "ipv4"},

{"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},

{"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],

"instructions":[{"apply_actions":[{"output":"NORMAL"}]},

{"meter":1}]

}

}

And I don't really understand the sense of these types of flow-tables.

- Why are there so diffrent ways to store the flows?

- What are the advantages of these types?

- Why is one called hardware flow-table and the other software flow-table?

- Would you explain me the context of TCAM <> hardware-table and SDRAM <> software-table?

- I try to understand why the "rule insertion engine" does not do anything on my HP2920 switch. According to HPE my switch is a ProVision-based switch which uses this "rule insertion engine". As mentioned above this engine does only replace flows with OpenFlow 1.0 (I use 1.3.0). But I do not try to replace flows, I just want to add one to flow-table 100 and with my flow I made the decision for the flow table without the "rule insertion engine"? Could you please explain me that engine?

After all this information I may understand why I have to use flow-table 200 for the write-action instruction.

Best Regards Tobias 

[ShaunWackerly]

Hi Tobias,

This is an excellent question. The difference in tables is due to our switch system design, as it relates to performance, cost, and functionality. Our products have multiple embedded CPUs which perform management functions (changing config, sending pings, etc) and also program our proprietary ASICs. These ASICs enable us to forward traffic at wire speeds, which is not possible with only a small CPU. The goal of the CPU is to program the ASIC in such a way that all traffic is forwarded by the ASIC, however this is not possible in all cases. In the cases where the ASIC does not support a specific condition, the CPU must forward the traffic. Since the ASIC is a custom-built and specialized component, it does some things very, very quickly but isn't capable of doing everything that a general-purpose CPU can do.

In the paper you referenced, they saw 2% wire speed because they hit a condition where the CPU was forwarding traffic. If I'm doing my math correctly, a 1Gb port can see 1024*1024*1024 = 1,073,741,824 bits of traffic per second. That translates to 134,217,728 bytes/second, or in the case of 64-byte packets it would be 2,097,152 packets/second. Depending on what other tasks our CPU is doing, it can usually forward 1,000-4,000 packets/second, so that's where you get the <2% number from the paper.

In the paper they were using an older version of OpenFlow (1.0) which didn't allow the controller to choose a hardware or software table. The newer version of OpenFlow (1.3) has this capability, as you've seen. The "rule insertion engine" was necessary in OpenFlow 1.0 because the switch needed to compute which flows could be put into the hardware table without masking flows that were put into the software table. For your purposes (OF 1.3), the "rule insertion engine" logic has been offloaded to the controller, so the controller now makes that decision when it chooses the table.

As long as you specify table 100 for the flow, it will be pushed into the hardware (ASIC-based) table. This will give you the highest performance possible, but it also has some limitations in terms of what is supported and how it can scale. We introduced different pipeline models to give admins/controllers greater flexibility in making this choice. You're using the standard pipeline which has 2 tables (100, 200) with ~1,000 entries in the hardware table. Our newer products (2930,3810,5400Rv3) support a custom pipeline which has a customizable number of tables (1-12) and potentially 64K exact-match and 8K wildcardable entries in the hardware.

I hope this helps.

Shaun

[Tobias-hab]

Hi Shaun,

thanks a lot for your answer this helped me a lot to understand this issue. In your last answer you have mentioned nevertheless that it is possible to realize the write action instruction with the help of the software flow table 200 on my 2920-Switch? Could you please give me a hint or example how to put this into practice? 

Tobias 

[ShaunWackerly · Accepted solution]

Hi Tobias,

Going from the flow in your original post, the changes you'd need to make to use write actions in table 200 would be (highlighted):

{
  "flow":{
    "priority":50100,
    "table_id":200,
    "match":[
      {"eth_type": "ipv4"},
      {"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},
      {"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],
    "instructions":[{"write_actions":[{"output":"NORMAL"}]},
    {"meter":1}]
  }
}

Shaun

[Tobias-hab]

Hi Shaun,

thanks for your information, but I have to delete the meter-field in the instruction section, as we already figured out that it is not possible to create a flow in flow table 200 with a corresponding meter. 

After our "discussion" I did not expect that is it such easy. 

Tobias 

[ShaunWackerly]

Hi Tobias,

Would it be an option to put one flow into table 100, to get the meter:

{
  "flow":{
    "priority":50100,
    "table_id":100,
    "match":[
      {"eth_type": "ipv4"},
      {"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},
      {"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],
    "goto_table":200,
    {"meter":1}]
  }
}

and another flow in table 200 to get the write-actions behavior?

{
  "flow":{
    "priority":50100,
    "table_id":200,
    "match":[
      {"eth_type": "ipv4"},
      {"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},
      {"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],
    "instructions":[{"write_actions":[{"output":"NORMAL"}]}]
  }
}

Shaun

[Tobias-hab]

Hi Shaun,

meanwhile I have ordered two 2930 Switches for further investigation. I have already tried the way you recommended it in your message. I have changed the syntax a little bit to make it possible to work: 

{
"flow":{
"priority":50100,
"table_id":100,
"match":[
{"eth_type": "ipv4"},
{"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},
{"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],
"instructions":[{"goto_table":200},
{"meter":1}]
}
}

The problem here is the use of the meter. This causes not only the flow to fail, even more that flow, however, crashes my whole openflow instance on the given switch, so that I lose every self made flow. The error message on the switch also says that it is not possible to use the goto-table command and the meter command together in one flow.

... 0010:23:10:32.16 OPFL eOFNetTask:RX from tcp:192.168.57.23:6633: 0:
0010:23:10:32.16 OPFL eOFNetTask:{ "error_code":"OFPBAC_BAD_TYPE","error_reason"
:"Rule with a dscp remark meter and (OFPP_CONTROLLER OR goto) action is not
supported","process_time":"0.316 ms","command":"OFPFC_ADD","table_ ....

Without the meter command the flow works fine and forwards to flow-table 200.

So I stay with apply_actions on the 2920 switch and invest more time in the 2930 switch series when they arrive.

Tobias 

[ShaunWackerly]

Tobias,

My apologies, I forgot about the restriction where meter and goto cannot be used in the same flow. With the 2930, if you use VAN 2.8 then you'll be able to use the 2930's custom pipeline to make use of the write_actions instruction. Are you able to explain why you'd prefer write_actions over apply_actions in this scenario?

Shaun