Software Defined Networking
1748246 Members
3499 Online
108760 Solutions
New Discussion

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

 
SOLVED
Go to solution
soginy
Occasional Advisor

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

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)

 

 

4 REPLIES 4
soginy
Occasional Advisor

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

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

ShaunWackerly
HPE Pro

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

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

I am an HPE Employee
soginy
Occasional Advisor

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

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)

ShaunWackerly
HPE Pro
Solution

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

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

I am an HPE Employee