SD-WAN

Hello,

I am trying to configure an HP switch (HP-2920-48G-POEP) via OpenFlow 1.3 using the HPE VAN SDN Controller.
What I'd like to do is add a flow that mirrors all traffic through a single port and then processes it normally.

It seems to me that what I'd like to do is add a flow that matches all traffic on all ports and then takes two actions: 
Output=NORMAL and 
Output=<port #>
But the controller keeps rejecting all the flows I create or ignoring one of these output statements.

Can anyone help?

Hi sprogrs2,

Could you please post the flow (either JSON format or a description of all matches/instructions) which you are attempting to push to a 2920? I ask because the 2920 uses a slightly older ASIC, therefore it doesn't have all of the match/action capabilities that a 2930, 3810, or 5400R would.

Specifically, I don't believe the 2920 can match ethernet destination (MAC), so if your flow is attempting to match eth_dst then it would be rejected for that reason.

In addition to posting the flow you're trying to push, could you please also have the following commands enabled on the 2920 when you're attempting to push the flow? These may give additional output on the switch console to explain why the flow was rejected:

• debug openflow
• debug destination session

(to remove these commands, just use "no debug destination session" and "no debug all")

Shaun

HI Shaun,

Thanks for the response. Sorry for the delay getting back, I was out of the office.

The match I would like to configure is as follows.

For all packets on a given VLAN, do the normal thing AND also output to a port.

SO match VLAN ID = 63, Output port 25 AND Output NORMAL (?)
Currently using FlowMaker (have also tried via CURL) , and trying to put this in table 100 but I'm getting the following error:

Failed to validate flowmod: {ofm:[V_1_3,FLOW_MOD,104,2138062],cmd=ADD,match={Match(V_1_3):[type=OXM,len=10],fields=VLAN_VID},...}

Hi Shane,

It looks like you're hitting a limitation on the 2920. I tried pushing the following flow to a 2920 running 16.03.0003:

{
    "flow": {
        "priority": 1000,
        "idle_timeout": 0,
        "hard_timeout": 30,
        "cookie": "0",
        "match": [
            {
                "vlan_vid": "63"
            }
        ],
        "instructions": [
            {
                "apply_actions": [
                    {
                        "output": "25"
                    },
                    {
                        "output": "NORMAL"
                    }
                ]
            }
        ]
    }
}

I had the debug commands enabled on the switch, so at the switch console I saw the following error message which explained the reason for the flow being rejected:

HP-2920-48G# debug destination session
HP-2920-48G# debug openflow errors
HP-2920-48G#
0000:00:42:29.18 OPFL eOFNetTask:RX from tcp:10.0.10.27:6633: 0:
0000:00:42:29.26 OPFL eOFNetTask:{ "error_code":"OFPBAC_BAD_TYPE","error_reason"
   :"Rule with output combination of OFPP_NORMAL + (Physical port OR OFPP_FLOOD
   OR OFPP_IN_PORT) is not supported","process_time":"0.271 ms","com
0000:00:42:29.50 OPFL eOFNetTask:mand":"OFPFC_ADD","table_id":100,"cookie":"0x0"
   ,"cookie_mask":"0x0","idle_timeout":0,"hard_timeout":30,"priority":1000,"buff
   er_id":"0xffffffff","out_port":"0xffffffff","out_group":"0xffffff
0000:00:42:29.74 OPFL eOFNetTask:ff","flags":"0x0","match":{"vlan_vid":"63"},"in
   sts":[{"apply_actions":[{"outport":25},{"outport":"normal"}]}]}

There are two ways I can think of to work around this limitation:

1. Upgrade to a 2930F. I tried the same flow (above) on a 2930F running 16.03.0003 and it was accepted.
2. Use an SI tunnel instead of a physical port. As noted in the error message above, this combination is not supported with a physical port. However, I believe it is supported with an SI tunnel (as used by our HPE Aruba Protector application). The only downsides to using SI tunnels for your application would be that the packets would be encapsulated (so you'd have to decapsulate them, or add another switch for decapsulation) and that you'd be limited to a total of 4 (I believe) SI tunnels per box.

Could you let us know if either of these solutions would work for you?

Shaun

Hey Shaun,

Thanks for the suggestions, but I actually got this to work by moving the flow to table 200.

Shane

Glad to hear it is working now, Shane. My apologies for not including that as a potential option in my reply. If you didn't already know this, any flows in table 200 will be handled using the switch CPU. This effectively limits the number of packets-per-second that the flow could handle to a small rate (~1,000/sec). Make sure your solution doesn't see performance spikes above that threshold, otherwise you could end up with dropped packets.