Hi, The problem which I've discussed was removing the openflow error messages.(solved now) Now, The opeflow.discovery works properly using --explicit_drop=False. I've sent full packet to the controller as the other solution and it's worked as well.(Thanks Tim) BTW, the version of the FlowVisor used at OFELIA is 0.8.1.
I truly appreciate your help. Best regards, Farzaneh From: Murphy McCauley [mailto:murphy.mccau...@gmail.com] Sent: Monday, 13 October 2014 4:20 PM To: Farzaneh Pakzad Cc: Tim Upthegrove; pox-dev@lists.noxrepo.org Subject: Re: [pox-dev] OFPBRC_BUFFER_UNKNOWN in OFELIA testbed That's probably annoying, but I don't think it should actually stop anything from working. You should be able to shut it up by passing --explicit_drop=false to openflow.discovery. Or, for that matter, --no_flow should work too. Offhand... full_payload wouldn't have an affect here, since that's just for things that miss the table. In this case, it should be hitting the rule that discovery installed (unless you pass --no_flow), which also specifies full payloads. There's probably nothing illegal spec-wise about sending both buffer_ids and full payloads, though it's sort of unusual and Flowvisor is probably responsible. Though as I said, I think this should be mostly cosmetic. You say the problem hasn't been solved yet. Which problem, specifically? -- Murphy On Oct 12, 2014, at 10:46 PM, Farzaneh Pakzad <f.pak...@uq.edu.au<mailto:f.pak...@uq.edu.au>> wrote: Hi Murphy and Tim, Thanks a lot for your comments. having gotten your idea about capturing the packets and sending full-payload of the packets to the controller, finally I ran the following command in POX: ./pox.py misc.full_payload openflow.debug openflow.discovery Unfortunately the problem hasn't been solved yet. The openflow error message "type: OFPET_BAD_REQUEST (1) Error: code: OFPBRC_BUFFER_UNKNOWN (8)" is still remained and the related OpenFlow error message in Wireshark is as follow: OpenFlow Protocol Header Version: 0x01 Type: Error (SM) (1) Length: 28 Transaction ID: 0 Error Message Type: Request was not understood (1) Code: Specified buffer does not exist (8) Data: 010d00100000001d643829a000070000 OpenFlow Protocol Header Version: 0x01 Type: Packet Out (CSM) (13) Length: 16 Transaction ID: 29 Packet Out Buffer ID: 1681402272 Frame Recv Port: 7 Size of action array in bytes: 0 Output Action(s) Warning: No actions were specified When I've compared the packets captured in Wireshark in a real testbed (OFELIA) with packets captured in my local machine, I realized something strange happend. (running openflow.discovery the controller sends packet_out messages to all switches, instructing them to send a LLDP packet via each of its ports. When an LLDP packet is received by a switch at the other end of the link, the switch sends a packet_in message to the controller, and the controller can detect a link between these two switches/ports). I have been experiencing an extra packet_out from the controller after receiving each packet_in message from the switch- to detect a link. An strange thing here is a buffer_id number alongside packet_in messages, while there shouldn't be any buffer id as I used "misc.full_payload" and that extra packet_out has the same buffer_id with " No actions were specified" which I think triggers the OpenFlow error message. I really appreciate any insights or suggestion regarding this problem. Thanks so much. Best regards, Farzaneh ________________________________ From: Tim Upthegrove [tim.upthegr...@gmail.com<mailto:tim.upthegr...@gmail.com>] Sent: Friday, 10 October 2014 10:59 PM To: Farzaneh Pakzad Cc: pox-dev@lists.noxrepo.org<mailto:pox-dev@lists.noxrepo.org> Subject: Re: [pox-dev] OFPBRC_BUFFER_UNKNOWN in OFELIA testbed Hi Farzaneh, I would also suggest that in general, if you are using a shared testbed of hardware OpenFlow switches, you might not want to rely on the switch buffers anyway. The availability of the buffers is not something you can really control, so it can be hit or miss. That is somewhat side-stepping the issue you asked about, but it is my 2 cents. There are instructions for getting the full payload in your packet-ins in pox at: https://openflow.stanford.edu/display/ONL/POX+Wiki#POXWiki-HowdoIgetswitchestosendcompletepacketpayloadstothecontroller%3F You would likely need to modify your controller logic as well to handle the packet-outs/flowmods appropriately after the payloads arrive. -- Tim Upthegrove On Thu, Oct 9, 2014 at 11:47 PM, Murphy McCauley <murphy.mccau...@gmail.com<mailto:murphy.mccau...@gmail.com>> wrote: Flowvisor can certainly cause issues which don't generally come up under non-Flowvisor use. The first thing you might do is see if you can find out which version of Flowvisor is being run and see if this is a known issue. Bug FLOWVISOR-133, for example, describes something which could certainly cause the behavior you're seeing (though it's now quite old). The next thing you can do to try to understand what's happening is to capture the OpenFlow traffic (you can use POX's openflow.debug component or tcpdump or wireshark or whatever) and examine it. You can associate the errors with the specific OpenFlow command that caused them and see if there's anything noteworthy. Looking at the timestamps, the number of events, the specific messages which caused the errors, etc. -- Murphy On Oct 9, 2014, at 3:24 PM, Farzaneh Pakzad <f.pak...@uq.edu.au<mailto:f.pak...@uq.edu.au>> wrote: Hi Murphy, Thanks a lot for your reply. Regarding to the first question: What components were you running in POX? I ran the openflow.discovery component of pox to detect the switches and links between them. (I also ran the forwarding.l2_learning switch and again I get this error: OFPBRC_BUFFER_UNKNOWN and other Openflow error messages such as flow mod failed ) And the second one: And is OFELIA raw hardware or are you running under Flowvisor? OFELIA is running under Flowvisor according to the below information from this link: http://www.fibre-ict.eu/index.php/cmf/ofelia "In order to slice the OpenFlow resources to support multiple experiments and users, the Expedient system, from which OFELIA inherits some of the most important features, make use of 4 layers: at the bottom are OpenFlow switches, then on top of them, the Flowvisor, the Opt-In Manager, and finally the OpenFlow Expedient connector. The Flowvisor is the most necessary part to isolate and support multiple experiments. At an abstract level, Flowvisor is a transparent proxy between many islands with OpenFlow switches and OpenFlow controllers used in a certain slice. Basically, the Flowvisor(s) present in each island (or provider) monitors OpenFlow protocol messages from and to the controllers, ensuring that each slice defined by the FlowSpace (a set of header values defined to isolate experiments) operates on traffic within that space." Best regards, Farzaneh From: Murphy McCauley [mailto:murphy.mccau...@gmail.com] Sent: Thursday, 9 October 2014 5:10 PM To: Farzaneh Pakzad Cc: pox-dev@lists.noxrepo.org<mailto:pox-dev@lists.noxrepo.org> Subject: Re: [pox-dev] OFPBRC_BUFFER_UNKNOWN in OFELIA testbed It might be much easier with more information. What components were you running in POX? And is OFELIA raw hardware or are you running under Flowvisor? -- Murphy On Oct 8, 2014, at 6:57 PM, Farzaneh Pakzad <f.pak...@uq.edu.au<mailto:f.pak...@uq.edu.au>> wrote: Hello everybody, I don't know if it is a relevant question to ask here: I am trying to do OpenFlow topology discovery (with pox) in real testbed called OFELIA. I've chosen some switches form one of the island to run the test. After I did all the settings, the controller started to work and detect the switches and links between them. However, in the meantime there are some openflow error messages and warnings as well. These errors are as follow: """ ERROR:openflow.of_01:[00-00-00-00-00-02|512 2] OpenFlow Error: [00-00-00-00-00-02|512 2] Error: header: [00-00-00-00-00-02|512 2] Error: version: 1 [00-00-00-00-00-02|512 2] Error: type: 1 (OFPT_ERROR) [00-00-00-00-00-02|512 2] Error: length: 28 [00-00-00-00-00-02|512 2] Error: xid: 0 [00-00-00-00-00-02|512 2] Error: type: OFPET_BAD_REQUEST (1) [00-00-00-00-00-02|512 2] Error: code: OFPBRC_BUFFER_UNKNOWN (8) [00-00-00-00-00-02|512 2] Error: datalen: 16 [00-00-00-00-00-02|512 2] Error: 0000: 01 0d 00 10 00 00 00 18 9e 11 2d 2c 00 06 00 00 |..........-,....| """ """ INFO:packet:(lldp tlv parse) warning TLV data too short to parse (86) INFO:packet:(lldp parse) error parsing TLV """ Would you please help me with that? I would like to know if anyone had this problem before and what makes this problem to happen and if I can solve it or not? Thank you all. Farzaneh
