SD-WAN

When I use the follwing CURL command (via the HP VAN SDN Controller 2.0) to introduce a new Flow inside a switch HP 3800-24G-2SFP:

curl --header 'X-Auth-Token: 30621afaccdd4c74b7573abe15682dd0' --header "Accept: application/json" --header "Content-type: application/json" --fail -ksSfL -X POST -d '{"flow":{"priority":100,"table_id":100,"idle_timeout":60,"match":[{"in_port":15},{"eth_dst":"ff:ff:ff:ff:ff:ff"},{"eth_src":"00:23:32:cf:89:bc"},{"eth_type":"ipv4"}],"instructions":[{"apply_actions":[{"output": 5}]}]}}' --url https://130.223.16.128:8443/sdn/v2.0/of/datapaths/00:14:f0:92:1c:21:fa:c0/flows

It workss. The flow is correctly introduced into the switch.

If I use  the same CURL (I've just changed the vpid) for a switch HP 3500-24G:

curl --header 'X-Auth-Token: 30621afaccdd4c74b7573abe15682dd0' --header "Accept: application/json" --header "Content-type: application/json" --fail -ksSfL -X POST -d '{"flow":{"priority":100,"table_id":100,"idle_timeout":60,"match":[{"in_port":15},{"eth_dst":"ff:ff:ff:ff:ff:ff"},{"eth_src":"00:23:32:cf:89:bc"},{"eth_type":"ipv4"}],"instructions":[{"apply_actions":[{"output": 5}]}]}}' --url https://130.223.16.128:8443/sdn/v2.0/of/datapaths/00:14:3c:4a:92:fa:cd:80/flows

curl: (22) The requested URL returned error: 400 Bad Request

In this case I have the previous error.

I

don't understand why my 3800 and my 3500 have to different behaviour with the same CURL.

Both switch have the same firmware: 15.14

Here is the configuration file fore 3500:

snmp-server community "public" unrestricted

openflow
controller-id 1 ip 130.223.23.100 controller-interface vlan 23
instance "unil"
listen-port
member vlan 20
controller-id 1
version 1.3
enable
exit
enable
exit

vlan 1
name "DEFAULT_VLAN"
no untagged 3,5-24
untagged 1-2,4
ip address dhcp-bootp
exit

vlan 20
name "sdn-client"
untagged 5-23
no ip address
exit

vlan 23
name "sdn-cnt"
untagged 24
tagged 1-2
ip address 130.223.23.104 255.255.255.0
exit

Here ie the configuration file for 3800:

Startup configuration: 27

; J9575A Configuration Editor; Created on release #KA.15.14.0003
; Ver #05:09.ff.ff.3f.ef:dc

hostname "hpmax1"
module 1 type j9575x
sntp server priority 1 130.223.8.20 4
telnet-server listen oobm
time timezone 1
snmp-server community "public" unrestricted

openflow
controller-id 1 ip 130.223.23.100 controller-interface vlan 23
instance "unil"
listen-port
member vlan 20
controller-id 1
software-flow-table 4
version 1.3
enable
exit
enable
exit

oobm
ip address 130.223.38.8 255.255.252.0
ip default-gateway 130.223.36.1
exit

vlan 1
name "DEFAULT_VLAN"
no untagged 2,5-24
untagged 1,3-4,25-26
ip address dhcp-bootp
exit

vlan 20
name "sdn-client"
untagged 5-23
no ip address
exit

vlan 23
name "sdn-cnt"
untagged 24
tagged 1-2
ip address 130.223.23.101 255.255.255.0
exit

Did someone had the same kind of bahaviour ?

Regards,

Serge

Hi sbotkine,

Thanks for your questions.

The observed behavior where the same flow is not getting added to the 3500 is because of the difference in hardware capabilities. The 3500 cannot accommodate a flow that has MAC addresses as match keys in hardware whereas the 3800 can. This is why the flow gets installed in table 100 (which is a hardware table) for the 3800 but not for the 3500. This fact should be clear from the hardware match charts in the OpenFlow administrator’s guide.

Note: However, there was an error in the captions used for the hardware match charts in pages 68, 69 and 70 of the OpenFlow administrator’s guide. We had requested that this be updated but I am not sure if this has been done.

Please do let us know if you need any further assistance regarding this query.

Please reply incase you have more questions around the same topic or open a new thread if new topic.

If you feel this isuses is resolved, please do let us know by marking response as an 'accepted solution’.

Thanks,

Leo

Hello Leo,

because of the inability to match hardware mac addresses of v1 hardware and 2920 v2 hardware in hardware it renders the switches usless for practicial applications because the throughput drops from 96 Gbps that the switches can support when they operate in legacy mode to 80 - 130 Mbps when operating in OpenFlow mode as a result of being CPU bound. This results I measured myself using netio with several v1 modules (3500 POE/POE+ and 5400 with v1 modules). So the only models which are usable for practical applications are 3800, 5400 with v2 modules and 8200 with v2 modules and Comware switches 5900, 5500 and 4800. I conducted the same test on two 5900 which provided me with wire speed throuhput without hogging the CPU at all. Since you have insight in the topic I wonder if you have a timeline for 5800 OpenFlow support? If the Comware OpenFlow hardware supports IPv6 matching in hardware? And if there is a timeline for matching IPv6 in hardware for v2 switches? I also wonder if you can recommend an OpenFlow controller which supports IPv6 neighbour discovery to test with Comware switches? And if there is a timeline for IPv6 support for the HP SDN controller?

I have not tried but hope that OpenDayLight will work with Comware and IPv6. From my point of view that is the most promising project to have something usable in the near future. All other projects seem to be orphaned or do not support OpenFlow 1.3 or don't have IPv6 support.

Personally I'm especially interested in Layer 2 Load Balancing, IPv4 and IPv6 policy based routing, ACLs and BGP because this is what I currently need and the current legacy Comware 5800 implementation has a completly broken ACL matching: It applies Layer 3 rules on Layer 2 for IPv4 traffic but it is documented otherwise. IPv6 acls don't match traffic with optional headers, PBR for IPv6 does not allow to use link local addresses for next hops and the ACL logging does not provide any information whatsoever of whom has triggered the ACL, also the duplicated IPv4 address detection is not functioning. I'm quite disappointed because I had big hopes for Comware based switches. 

Cheers,

   Thomas

---

ThomasGlanzmann wrote:8200 with v2 modules and Comware switches 5900, 5500 and 4800. I

---

Well, I still try to push some useful / working code to my 4800 devices. What tests/code did you run to "benchmark" the hardware throughput?

Hello,

I hooked up two 5900 to a HP SDN 2.0 controller which was running 200 KM appart using socat and a ssh port forwarding. Than I connected two clients to one switch and booted grml a Debian based live distribution. On that systems I configured IP addresses statically and download netio-linux. One was the client the other one was the server. I could see a throughput of 112 MB/s which is roughly 1 GBIT/s as it is supposed to be. Than I looked at the installed flows which were based on src/dst mac address and ports. And I looked at the CPU consumption which was 0. I also did a ping between two systems which was below 0.3 ms. When I did the same test with v1 hardware. The ping was 1.3 ms and the throughput depending on the strength of the CPU of the switch was between 8 MB/s till 13 MB/s (roughly 100 Mbit/s). After that I connected two more clients and two more switches and wired the switches redundantly. They were unable to use the additional link for more bandwidth, so that I had two netio servers both on one switch and two netio clients both on another switch running I saw that they split the 1 Gbit/s between the clients the reason for that was the redudant link between the switches being disabled. Topology changes were detected below one second so when I pulled the cable it changed below one second and when I put it back it also worked and when I pulled the other cable again it also worked. You could see the throughput decreasing from 112 MB/s to 58 MB/s and than going back up. My next try will be hooking OpenDayLight to Comware switches and than try IPv4 routing and than IPv6 routing with comware switches.

Cheers,

     Thomas

Hi Thomas,

Thanks again for all the responses.

Some of these HP switch related questions have been answered in another thread.

(http://h30499.www3.hp.com/t5/SDN-Discussions/Layer-3-Switch-using-OpenFlow-Routing-in-Hardware-for-IPv4-and/td-p/6327745#.UvPmfk2x5UZ )

The v1 modules and v1 module based switches would be useful depending on what application you are trying to use. It is a fact that such switches do not support match or rewrite of MAC addresses via OpenFlow in hardware. If the application of choice was routing which requires MAC rewrites, then the throughput would be limited as such operations would happen via the CPU and not the ASIC.

On the other hand, if the application was like a QoS application that matched on IP layer fields and had to change the IP ToS setting for QoS, this could be supported in hardware on the v1 based switches.

As you can tell we support significant enhanced capability in hardware on the v2 based switches.

If you feel we have answered your question, please let us know by marking this response as an 'accepted solution’.

Thanks,

Leo

Hi Thomas,

As you asked the question (“If the Comware OpenFlow hardware supports IPv6 matching in hardware?), the answer is yes, support ipv6 matching by h/w.

Again for other question (“And if there is a timeline for matching IPv6 in hardware for v2 switches?”), Could you please share your requirement/specific question about this?  

Thanks,

HP SDN Team

Hello,

my requirements are:

- Route IPv4 and IPv6 in hardware

- Policy Based Routing for IPv4 and IPv6 depending on the source address

- IPv4 and IPv6 ACLs

- Have a middle box which does NAT for IPv4 on internet access

- Utilize redundant links

- Mitigate unallowed DHCP server and IPv6 route advertisements

- Layer 2 seperation on VLANs

- Jumbo Frames

- Multicast Routing between VLANs

- BGP routing

Cheers,

       Thomas

Hello Thomas,

All the requirements what you had mentioned in the earlier post is supported in the Comware switches but not all requirements applicable to one  switch.

Can you please shed some light on your topology and the target switch you have configured?

It addition it would be good if you can help us understand on the need of “ Utilize  redundant links”  what is that you would like to achieve here.

Thanks

HP SDN Team

Hi Thomas,

The next controller code release (2.2) will have a mode setting (hybrid.mode) that allows the controlled switches to operate in a traditional setup, but retaining OpenFlow's ability to override the forwarding decision. This effectively lets you use a traditional switching setup (with all of the features that you listed above) but OpenFlow can override any forwarding decision you'd like it to override using an app that you write. That next controller release will support the 3800 in this hybrid.mode, and I believe the 3800 supports all of the functionality you listed.