SD-WAN

I've been trying to use version 2.4.3.0595 and previously version 2.3.5.6505 of the HP VAN SDN controller to add flows with matches for the ipv6_flabel (IPv6 flow label) and vlan_vid using the REST API.  For both matches and for both versions of the SDN controller I have received 201 (Created) HTTP code responses back from the request much like I do with add flow requests with different matches.  However, when I look at the list of flows for the switch the new flow has not been added.  Below is the specific JSON I sent in the add flow POST request to the REST API:

{"flow": {"priority": 30000, "table_id": 102, "match": [{"eth_type": "ipv6"}, {"ipv6_flabel": "0x17"}], "instructions": [{"apply_actions": [{"output": "NORMAL"}]}, {"meter": 1}]}}

I also tried set the ipv6_flabel as a decimal number (i.e. 23 and a hex number without quotes i.e. 0x17) and both had the same outcome of getting a 201 (Created) response but this did not cause the flow to appear in the list of flows for the switch.

I have found when previously adding other types of flow, that if I used a different table ID, e.g. 101, the flow would not be added to the switch but for various other flows with matches for ip_proto, eth_type, ipv4_src, ipv4_dst, ipv6_src, ipv6_dst, and ip_dscp, I have no problems with the flows being added to the switch if I set the table ID to 102.

I am using an HP 2920-24G switch running 15.15.0006 firmware.  I have noticed that version 15.16.0004 of the fimrware has now been released but the release notes do not make any reference to any issues like I have described.

I have also noticed that when I try to use the ip_dscp match with IPv6 (i.e. IPv6 traffic class) this seems to match any IPv6 traffic whatever the traffic class is and even if no traffic class is set.  This is despite the flow successfully appearing on the switches list of flows and ip_dscp working as expected with IPv4 traffic.  I have been using iperf3 to test this but I am pretty sure it is setting the traffic class properly when I inspect the packets using TCPDump.

If anyone has any advice on what I might be doing wrong or have any similar experiences it would be good to know because I don't know how to dig any deeper into what might be causing these issues.

Hello,

How are you creating/viewing the flows?

Are you strictly using the RSDOC interface?

Can you capture a wireshark trace showing the OpenFlow signalling?

Have you tried adding/viewing the flows with the CURL command? (i.e. bypassing the Controller)

Are you able to add/view other new flows into the switch?

Thanks,

Scott

> ScottReeve wrote:
>Hello,
>
> How are you creating/viewing the flows?

I am using the hp-sdn-client library describe at https://hp-sdn-client.readthedocs.org/en/latest/

I have hack this slightly to so I can see the JSON that will be submitted in the request before it is posted.

> Are you strictly using the RSDOC interface?

I have to admit I hadn't discovered this until you mentioned it.  I will have a look and the documentation and see if I can figure out how to replicate the request using this interface.

> Can you capture a wireshark trace showing the OpenFlow signalling?

As the controller server does not have a desktop interface, I assume it is fine to just do a TCPDump on the control plane interface, setting the appropriate WireShark output flag?    I will look into doing this shortly.

> Have you tried adding/viewing the flows with the CURL command? (i.e. bypassing the Controller)

When you mean bypassing the controller, I assume you mean the web page interface to the controller.  I have used the Python library's call to make a get flows request and that has the same list of flows.

> Are you able to add/view other new flows into the switch?

Yes.  I have been able to add metered flows with a number of different match types, as described in my original post.

> Thanks,
>
> Scott

Thanks and regards
 
David Newman
P.S. Sorry about my quoting syntax.  I am new to the forum and I am not sure the best way of marking up inline replies.

Attached is a tcpdump that should load in wireshark.  As I have multiple switches connected you need to look for packets that are going between 172.16.0.1 (controller) and 172.16.0.5 (switch).  These are also enabled on IPv6 on the IP addresses fd00:172:16::1 and fd00:172:16::5 respectively.  Whilst running TCPDump I made a request to add a flow with an ipv6_flabel match.

If you need me to do another TCPDump with a successful add flow request I can capture that as well.  Unfortunately, I am having some issue using Wireshark on my desktop at the moment (GTK issues).  Although the file does load in WireShark, I couldn't move between packets in the GUI interface without WireShark crashing so I do not know if any add flow messages were sent between the controller and the switch.

I had some problems attaching the file with a .pcap extension so changed it to .txt so it would upload.

Attachment(s)

tcpdump_control_plane.txt   703 B 1 version

Just to follow up, I used the RSDOC API web interface to add both a flow that I knew would work and the flow with the ipv6_flabel match and I got the same result as using the Python library for the REST API. I.e. the former worked and the latter still didn't work.