Software Defined Networking
1751894 Members
5414 Online
108783 Solutions
New Discussion юеВ

[HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

 
JuneKim
Occasional Collector

[HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

Hello,

I am a network researcher using HPE2920-24G and Ryu-manager as an SDN Controller. While I am testing IP routing by using these SDN switches, I've got some issues as follows. Could you please advise me on why I have encountered the issues and how to solve them. It would be greatly helpful to me.

1. Failure of negotiating Openflow version1.3. Can you please let me know what options of switches I should check first? 

When I try to negotiate the supported OpenFlow version between switches and controller, I've got that switches to return 0x1 which means only OpenFlow 1.0 supported. According to the manual of switches, it notices that they support openflow1.3 but I am struggling to communicate with them based on ver1.3.  

--- 
 unsupported version 0x1. If possible, set the switch to use one of the versions [4] on datapath ('192.168.1.83', 50972)

2020-06-02 15:48:11,074 unsupported version 0x1. If possible, set the switch to use one of the versions [4] on datapath ('192.168.1.83', 50972)

Error in the datapath None from ('192.168.1.83', 50972)

 

2. Based on my understanding, openflow1.0 does not support multi-table but why have I received that the table_id is 2?

Under openflow1.0 (I could not communicate with switches based on ver1.3 as prementioned),

I have added flow entries including SET_NW_DST, OUTPUT, and found that their table_id is 2 as below. I am just thinking that it is caused by dealing rules in the packet pipeline, however, it seems to lead to time delay or latency between ingress and egress.  

---

{"dpid": [{"actions": ["SET_NW_DST:10.0.0.100", "OUTPUT:13"], "idle_timeout": 0, "cookie": 0, "packet_count": 1, "hard_timeout": 0, "byte_count": 60, "duration_nsec": 282000000, "priority": 10, "duration_sec": 44, "table_id": 2, "match": {"dl_type": 2048, "nw_proto": 6, "nw_src": "10.0.1.10", "tp_dst": 80, "nw_dst": "10.0.0.7"}}]}\n

In short, I'd like to ensure if hpe 2920 supports openflow1.0 fully first, and how I can use the openflow1.3 based on the proper configuration of the switches. Based on my current configuration using openflow1.0, the throughput of IP routing on the switches is less than 60 kB/s and even transferring the segmented packet into PACKET_OUT on SDN controller has higher through at about 80 kB/s.

 

I appreciate your help in advance and look forward to seeing any response.

 

Best regards,

 

4 REPLIES 4
ADO_11
Advisor

Re: [HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

Can you describe little more, like whats in Data plane, control plane and mgmt plane.?

Suyash Agarwal
JuneKim
Occasional Collector

Re: [HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

Dear HPE Community Support Team,

I appreciated your reply.
The issue of mismatch in the version has been resolved as I've changed
the options in switches.

However, the throughput issues have still remained the same regardless
of the openflow version.I am wondering if there is a rate limitation
when the packets are controlled by flow rules on software tables in
2920. Does SW table has lower performance (e.g., packets per second)
than HW table in switches?

When I have checked the throughput (data rate) by using web server,
the bandwidth was only 20 MB/s per an HTTP request.
I've set the rule of changing src_ip or dst_ip in the edge switch and
it leads that flow rule is added in software table according to your
manual (table_id == 200)
One HTTP request requires about 2900 packets to send the 4 MB bytes of
web pages between a client and a server. A rate-limit at the software
level of switches seems to affect the data limitation when L3
switching is required in switches.

Otherwise, I've checked L2 switching (table_id == 100) based on the
same configuration getting rid of L3 actions in flow rules (changing
src_ip or dst_ip) and its performance has marked about 115 MB/s. I
have guessed that L2 switching could cover full bandwidth of links
while L3 switching seems to have limitations to populate packets to
related output ports.

In summary, could you please confirm me if both HW and SW switching in
2920 can guarantee the same performance or not. If not, how to improve
the performance in terms of a data rate in transit when flow rules are
added into software table.

For your information, I'd like to list up the configuration of my experiment.
1. SDN controller: Ryu
2. Switch: HPE 2920-24G switches

Thank you for your support in advance.

Best regards,
Minjune Kim
ADO_11
Advisor

Re: [HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

Hi Minjune,

I have been working for a long time for ACI and WBX Controller and can
confirm HW switching has better computing power than SW switching. So as
per me you should go for Software switching. nevertheless if you go that
way you will get more advanced features then the software one.

Only one thing that I could think wrong is, it will increase the costing of
infra.

Thanks and regards,

Ado*Planting a tree is much better than wearing a mask to be safe from**
pollution.*
Suyash Agarwal
JuneKim
Occasional Collector

Re: [HPE2920-24G] Only 0x1 returned at the version negotiation and low throughput on openflow1.0

Dear Suyash Agarwal and HPE Community Support Team,
 
Thank you for your prompt response.
We've already set up the SDN testbed by using HPE 2920 switches and I regret to say that we could increase infra of the testbed (e.g., replacing switches).
I have one more quick question, "What SDN controller is compatible with HEP 2920, ONOS or ryu?"
Have you ever experienced the performance degradation caused by a specific SDN controller?
 
At this moment, I am using ryu as a SDN controller but it seems to have general features independent on HW switches.
On the other hand, ONOS has supported HW-specific drivers in onos/drivers/hp/src/...
 
Of course, ONOS is now providing more features and functions than ryu-manager but I want to go through if there is any differences in terms of network switching performance in HPE 2920.
 
I so appreciated your reply in advance.
 
Best regards,
Minjune