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> 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] > Sent: Friday, 10 October 2014 10:59 PM > To: Farzaneh Pakzad > Cc: 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> > 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> 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 > 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> 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
