SD-WAN

I am unable to test this right away, but the only extraneous thing I see is the "tcp_dst":"80" ... can you try without the quotes around 80? 

Thanks a lot for your answer.

Meanwhile I found some other discussion here in this forum with the same problem. Furthermore I found the "Main-Problem" in my switch configuration. I had 2 problems:

1. On my HPE 2920 Switch I configured in my OpenFlow instance "table-num sw-table-1 0". But 0 seems not to be allowed, according to the other discussions. Finally I deleted this configuration. (See appendix picture "no_table_num").

2. The port in my above posted flow, isn't part of a VLAN which contains to my OpenFlow instance of_vlan. So I changed my flow a bit and used a correct port and that worked almost fine for me. Here my new flow:

{
"flow":{
"priority":50000,
"hard_timeout":60,
"table_id":100,
"match":[
{
"ipv4_src": "192.168.59.10"
},
{
"eth_type": "ipv4"
},
{
"in_port": 23
}
],
"instructions":[
{
"apply_actions":[
{
"output":24
}
]
}
]
}
}

There is one problem left:

Although I can send the flow now to my switch, I still get an "error" message (see picture error_json)

Code 201 seems to be okay, but this may leads to a problem I am not aware of?

Hope you know this report message. 

Regards Tobias 

Hi Tobias,

It looks like things are operating now. The '201' status code indicates 'created' and should be considered equivalent to 200 when testing for success. Regrettably the "Response Body" is highlighted in red in our JSON web interface, as shown in your "error_json.png" screenshot:

https://restfulapi.net/http-status-201-created

In general, when you see the REST API return a message that says "Failed to validate flowmod", a good rule of thumb is to enable OpenFlow debug messages on the switch. This will only be useful if the switch is in a controlled environment (because you'd be seeing debug for all OpenFlow operations), but it will tell you why the switch is rejecting the flowmod. In your case above, it would remove the guesswork as to what is wrong with the flowmod (ingress port). If you don't see any openflow debug output on the switch, then the flowmod is being rejected by the VAN controller (but that's a rarer case, usually caused by improperly-formatted JSON).

To enable OpenFlow debug on the switch, use:

debug openflow
debug destination session

Then to turn it off, use:

no debug all

I think the result of the "table-num sw-table-1 0" command would be that the switch would use table 0 in the pipeline as a software table, which means no hardware table would be used. For what it's worth, you should only need to use "table-num ..." commands if you're dealing with a non-VAN controller that doesn't understand the HPE Aruba switch pipeline. In all other cases, just using "pipeline-model standard" (tables 0,100,200) or "pipeline-model custom" (flexible tables, only available on 2930F, 3810, 5400R) should be sufficient.

I hope this helps!

Shaun

Hello Shaun Wackerly,

sorry for the late response and thank you for this information.  I use the Flow-Tables now in that way you mentioned it. I am going to add some other Meters via the REST API next time and there I will use the debug mode.

I hope this will help me there too. Thanks for your support!

Tobias