SD-WAN

 View Only
  • 1.  bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

    Posted Nov 06, 2017 11:09 AM

    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)

     

     



  • 2.  RE: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

    Posted Nov 06, 2017 11:12 AM

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



  • 3.  RE: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

    Posted Nov 07, 2017 02:16 PM

    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



  • 4.  RE: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

    Posted Nov 10, 2017 11:46 AM

    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)



  • 5.  RE: bad instruction error when using aruba 3810 switching with openflow 1.3 on Ryu

    Posted Nov 14, 2017 10:02 AM

    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