Software Defined Networking
1753826 Members
8796 Online
108805 Solutions
New Discussion

HP ProCurve 6600-24g-4xg

 
gojkog21
Advisor

HP ProCurve 6600-24g-4xg

Hi guys,

Can anyone tell me is it possible to change flow location from 'software' to 'hardware and software' in OpenFlow v1.0? Beceuse, in software mode is possible to forward only 100 pps by default, and speed is too slow.

Thanks,

Gojko

 

7 REPLIES 7
ShaunWackerly
HPE Pro

Re: HP ProCurve 6600-24g-4xg

Hi Gojko,

When using OpenFlow 1.0, the flow location (hardware or software) is automatically selected based upon what the device can support in its switching ASIC (matching, actions) and what else is in the table.

The two options you'd have to increase performance are:

  1. Configure the "openflow instance X limit software-rate" setting to a value higher than the default of 100pps. If you configure this value to the maximum (2,000pps) then other protocols running on the switch CPU may be impacted if you sustain high throughput. Note that setting the software-rate to 2,000pps does not guarantee that you'll achieve 2,000pps, it only raises the threshold for dropping packets.
  2. Configure OpenFlow 1.3 and push flows to table 100. In our standard OpenFlow 1.3 pipeline, table 100 is a hardware TCAM table and will likely achieve the performance you need.

Shaun

I am an HPE Employee
gojkog21
Advisor

Re: HP ProCurve 6600-24g-4xg

Hi,

Thaks for answer!

I've tried with limit software-rate on of v1.0, and set it to 10000 (maximum). But I can't reach 30 Mbits/second on Gigabit interfaces... I need more than 100 Mbits/sec.

So, I need to configure openflow v1.3. Could you tell me is the next command correct for pushing flows to table 100:

policy-table 0

 

 

ShaunWackerly
HPE Pro

Re: HP ProCurve 6600-24g-4xg

Hi Gojko,

The only command you'll need to use OpenFlow 1.3 (compared to 1.0) is

openflow instance X version 1.3 only

Once the controller connects to the switch, you'll see that the switch uses a 3-table pipeline with tables 0 (not used), table 100 (hardware) and table 200 (software). You'll want to push all of your flows to table 100, or use VAN's default table selection mechanism by leaving the table_id field blank in flows that you push.

If you are using the ONOS or POX controllers and they attempt to add a FLOOD rule by default, it should only affect the packets which are being flooded, not all flows (when using OF 1.3). You'd just need to push additional flows at a higher priority than the FLOOD rule.

Shaun

I am an HPE Employee
gojkog21
Advisor

Re: HP ProCurve 6600-24g-4xg

Hi Shaun,

Thanks for answering!

I need to know one more thing: Pox controller uses packet_out message with flood_action. That controller doesn't use flow_mod messege with flood_actions. So, is it expected behavior to have error, because packet_out doesn't change flow table??

Thanks,

Gojko
ShaunWackerly
HPE Pro

Re: HP ProCurve 6600-24g-4xg

Hi Gojko,

Are you saying that the switch responds with an ERROR when the Pox controller sends a packet-out message which has FLOOD as the destination port? It would be helpful if you enter the commands "debug destination session" and "debug openflow" on the switch, then send the packet-out message from Pox. The switch will generate debug output on the CLI which explains some details if an error occurs. Please try these steps and copy that output here.

Shaun

I am an HPE Employee
gojkog21
Advisor

Re: HP ProCurve 6600-24g-4xg

Hi Shaun,

Yes, the switch responds with an ERROR when received packet out message with flood action. You can see that on photos in attach.

Topology is there:  

host1-----------------(port1)HP Procurve(port4)--------------------host1

And I used hardware only flow location.

Thanks,

Gojko

ShaunWackerly
HPE Pro

Re: HP ProCurve 6600-24g-4xg

Hi Gojko,

Could you please let us know which firmware version you are using? This will help us narrow down why you're receiving the error. We'd recommend that you be on the 15.18 firmware, since that is the most recent firmware which supports the 6600 product.

The only case I'm aware of when the switch would return that ERROR is when a packet-out is sent to the LOCAL port. If you're able to upload a packet capture (tcpdump) of the control-plane conversation, that would ultimately be what would give us the information needed to identify root cause.

Shaun

I am an HPE Employee