topic Re: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu in Software Defined Networking

bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

soginy — Mon, 06 Nov 2017 16:08:30 GMT

i get this error when i try to use ryu with switch runing openflow 1.3. when i use openflow 1.0 it works fine. Error message below.

EventOFPErrorMsg received.
version=0x4, msg_type=0x1, msg_len=0x4c, xid=0x5022057a
`-- msg_type: OFPT_ERROR(1)
OFPErrorMsg(type=0x3, code=0x1, data=b'\x04\x0e\x00\x50\x50\x22\x05\x7a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x04\x00\x00\x00\x00\x00\x04\x00\x18\x00\x00\x00\x00')
|-- type: OFPET_BAD_INSTRUCTION(3)
|-- code: OFPBIC_UNSUP_INST(1)
`-- data: version=0x4, msg_type=0xe, msg_len=0x50, xid=0x5022057a
`-- msg_type: OFPT_FLOW_MOD(14)

Re: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

soginy — Mon, 06 Nov 2017 16:12:08 GMT

just to add more information. i am using the simple_switch_13.py ryu app

Re: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

ShaunWackerly — Tue, 07 Nov 2017 19:15:51 GMT

Hi soginy,

It looks like the RYU app is attempting to use an instruction which is not valid for the 3810. Could you please let us know whether you're using the "pipeline standard" or "pipeline custom" setting on the 3810? You could also just copy the output of "display this" when you're in the OpenFlow context.

Additionally, I'd recommend that you use the following two commands on the switch to enable OpenFlow debug output. This will display detailed information about each flowmod, including the specific instruction which is being used, but is not supported:

debug destination session
debug openflow

Once you've gotten the output for the failure, you can turn off debug with "no debug all".

Shaun

Re: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

soginy — Fri, 10 Nov 2017 16:45:31 GMT

Thanks for the reply this is the output from the debug.

0000:05:41:39.69 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 : OFPT_HELLO
(OF 0x04) (xid=0x7):

0000:05:41:39.80 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0: OFPT_HELLO
(OF 0x04) (xid=0x59d25b4c):

0000:05:41:39.92 OPFL eOFNetTask:aggregate<->tcp:192.168.1.253:6633:0 connected
0000:05:41:40.00 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0:
OFPT_FEATURES_REQUEST (OF 0x04) (xid=0x59d25b4d):

0000:05:41:40.13 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 :
OFPT_FEATURES_REPLY (OF 0x04) (xid=0x59d25b4d):
dpid:000170106f91ab80
n_tables:3, n_buffers:0
capabilities: FLOW_STATS
TABLE_STATS PORT_STATS PORT_BLOCKED
actions:
0000:05:41:40.39 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0:
OFPT_STATS_REQUEST (OF 0x04) (xid=0x59d25b4e):

0000:05:41:40.52 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 :
OFPT_STATS_REPLY (OF 0x04) (xid=0x59d25b4e):

0000:05:41:40.64 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0:
OFPT_FLOW_MOD (OF 0x04) (xid=0x59d25b4f):

0000:05:41:40.76 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0: ***decode
error: OFPBIC_UNSUP_INST***
ADD priority=0 buf:0x0 insts=[drop]
0000:05:41:40.92 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 : OFPT_ERROR
(OF 0x04) (xid=0x59d25b4f): OFPBIC_UNSUP_INST
(***truncated to 64 bytes from
80***)
00000000 04 0e 00 50 59 d2 5b 4f-00 00 00 00 00 00 00 00
|...PY.[O.
0000:05:41:41.18 OPFL eOFNetTask:Instance aggregate: Exiting fail secure mode.
0000:05:41:49.68 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 :
OFPT_ECHO_REQUEST (OF 0x04) (xid=0x0): 0 bytes of payload

0000:05:41:49.82 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0:
OFPT_ECHO_REPLY (OF 0x04) (xid=0x0): 0 bytes of payload

0000:05:41:59.69 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 :
OFPT_ECHO_REQUEST (OF 0x04) (xid=0x0): 0 bytes of payload

0000:05:41:59.82 OPFL eOFNetTask:RX from tcp:192.168.1.253:6633: 0:
OFPT_ECHO_REPLY (OF 0x04) (xid=0x0): 0 bytes of payload

0000:05:42:09.69 OPFL eOFNetTask:TX to tcp:192.168.1.253:6633: 0 :
OFPT_ECHO_REQUEST (OF 0x04) (xid=0x0): 0 bytes of payload

This is part of the ryu simple_switch_13.py code i cannot see what the problem with the instruction is

class SimpleSwitch13(app_manager.RyuApp):
OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

def __init__(self, *args, **kwargs):
super(SimpleSwitch13, self).__init__(*args, **kwargs)
self.mac_to_port = {}

@SET_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def switch_features_handler(self, ev):
datapath = ev.msg.datapath
ofproto = datapath.ofproto
parser = datapath.ofproto_parser

# install table-miss flow entry
#
# We specify NO BUFFER to max_len of the output action due to
# OVS bug. At this moment, if we specify a lesser number, e.g.,
# 128, OVS will send Packet-In with invalid buffer_id and
# truncated packet data. In that case, we cannot output packets
# correctly. The bug has been fixed in OVS v2.1.0.
match = parser.OFPMatch()
actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
ofproto.OFPCML_NO_BUFFER)]
self.add_flow(datapath, 0, match, actions)

def add_flow(self, datapath, priority, match, actions, buffer_id=None):
ofproto = datapath.ofproto
parser = datapath.ofproto_parser

inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
actions)]
if buffer_id:
mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id,
priority=priority, match=match,
instructions=inst)
else:
mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
match=match, instructions=inst)
datapath.send_msg(mod)

Re: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

ShaunWackerly — Tue, 14 Nov 2017 15:01:32 GMT

Hi soginy,

Nothing obvious jumps out to me as the cause of the issue. It looks like the flow being pushed just matches some fields then steals all traffic to the controller, with no other actions. I'm not sure why that wouldn't be supported.

I don't see the table ID specified in the RYU code, but you should ensure that the flow is either being pushed to table 100 (hardware) or 200 (software). We have a table 0 for spec compliance, but it does not accept any flows from the controller, unless you renumber the tables in the switch configuration.

I forgot to mention that in 16.03 and 16.04 firmware we've greatly enhanced the OpenFlow debug output. Based on what I'm seeing below, it looks like you're running an older version of firmware before we added those enhancements, so the debug information provided is less complete. Would you be able to upgrade the firmware to the latest released version and then try these steps again? Once you do, it should give a reason that explains which instruction is not supported.

Shaun