Problem with Hardware-only flow location in HP 2920 w/POX

[Gaston_Borja]

Hi everyone!

First i am sorry for my english, i am from Argentina.

We have a HP 2920 Switch and we use POX controller (forwarding.l2_learning module) with this arquitecture

Host1 (10.0.0.2) ----------Switch-------- Host2 (10.0.0.3)

when we put flow location for default (Software and hardware) the iperf test give us a 23 Mbps rate, it is very poor, we have the software rate limit in 2000 pps. We want use the hardware only flow location with a hardware rate limit of 1000000 kbps but when we put the controller with that the switch doesn't work, we cant ping between hosts and we haven't conection. we read the manual and found this:

NOTE: An error is returned to the controller if the flow cannot be added in hardware and the flow-location is set as hardware-only.

 NOTE: Flows with an action to forward to multiple ports or all ports of a VLAN, such as flood, cannot be hardware accelerated. Such flows are handled in software. Changing flow location to hardware-only affects those flows.
For example, if a flow is added with action such as FLOOD, it can only go in software. This causes in a performance penalty or the flow not being programmed at all if running in hardware-only mode.

can i use hardware-only with this switch? My POX controller is added actions with multiple ports forwarding? i have to change the controller for another? (ODL, Floodlight, Beacon)

the instance and the switch are configure fine because we can use with software and hardware flow location.

thanks you so much

[ShaunWackerly]

Hi Gaston_Borja,

In order to determine whether this is a supported condition, I think we'll need more information. Could you please provide the following?

1. 2920 firmware version (WB.XX.XX.xxxx)
2. OpenFlow version (I assume OF 1.0, since i think that's the only version where "hardware-only" applies)
3. A packet capture (.pcap) of the flowmod being pushed by POX. This will tell us what is being requested and why it is rejected.

Alternately, if you could get us a packet capture of the entire OpenFlow handshake + flowmod (ie: from when the switch connects to when the flowmod is rejected) then that would include all 3 of the above.

[Gaston_Borja]

Thanks you for the quick answer

1) The switch has WB.16.01.0007 firmware version

2) you are right, we use OF 1.0

3) here are the pcaps and a few pictures of the switch configuration

 

when we use software and hardware flow location we have some flows in the switch (all of them in software location), but when we use hardware only we don't have flows in the switch.

and what is "Hardware table miss count"? the number is always growing

Thanks you

[ShaunWackerly]

I was able to look at the .pcapng files you uploaded and with the limited support of OF 1.0 dissection in wireshark (2.0.4), I was able to notice a few things:

1. The flowmod being pushed is using 0xffff (65535) as the output port. This translates to 'NONE'. Is that the intended output port?
2. The packet-out message which followed used 0xfff9 (65529, 'TABLE') as the output port. I'm not sure if our switches support 'TABLE' as an output port. This would explain why the packet-out message (frame 27) is being rejected with an OFPT_ERROR (frame 29) in the "hardware and software" packet trace.
3. It looks like the flowmod is attempting to match eth_dst when eth_type=0x0800 (IPv4). This is not supported on the 2920. This is identified in some screenshots which show "The rule has match criterion for MAC address" as the Reason Description. To resolve this you could replace the 2920 with a 2930F, or you could remove the ethernet src/dst as match criteria.

Is OpenFlow 1.0 the desired openflow version? Our switches perform much better with OpenFlow 1.3, where the hardware table (100) and software table (200) are called out explicitly.

I believe the "hardware miss table count" is just a count of the number of packets that are unable to match in the hardware, and therefore have been handled by the switch CPU (much lower throughput).

You didn't mention HPE VAN as an alternate controller option, but you may want to consider it. VAN will intelligently fit flows into the hardware/software table as the device supports it, using a table-selection algorithm when the caller pushes a flowmod with no table ID specified. Also, the device drivers in VAN are kept in sync with firmware releases so that new functionality in switches is automatically utilized by VAN as it becomes supported. :)

[Gaston_Borja]

Thanks you for the answer

we are new in SDN and we are trying to study this new arquitecture. We saw your answer and we think in changing the controller, maybe that is the problem. POX is basic and POX controller doesn't accept OF 1.3 neigther, and we don't have HP VAN license (We are in Argentina, it is expensive), we want to use RYU, Floodlight or ODL, but our question was if the switch can support hardware-only flow location, if the answer is yes then we will keep trying until we make it work fine.