Re: [openflow-discuss] Noob Question: Wildcards and ofp flow stat request
Rob Sherwood rob.sherwood@... writes: Hi Gopal, What you're doing seems to be right, but my (very arbitrary) guess is that you either have some endian issues or are not packing the message correctly. The way to check is to grab the openflow wireshark dissector from the openflow reference implementation. Let it to parse your messages and make sure that all of the bits are where you think they are. If that all works out, it's possible (though hopefully less likely) that you've found a bug in the switch you're using -- what switch are you using? - Rob . Hi Rob Thanks for your response. I was using openflow 1.0.0 userspace switch within a virtual box. The controller was a modified one from openvswitch_1.1.0_pre2 (hence, both should be using the same protocol 1.0). Wireshark seemed to parse everything ... except, the match fields (but not the wildcards) were missing in both OFP_STAT request and response. So I switched to using the openvswitch ( and now wireshark could see all the match fields correctly and my search operations are now working as expected. Not sure why it works with openvswitch but not with openflow switch (since the protocol should be exactly the same), but I think I am going to leave it at that and continue with openvswitch. regards Gopal Agrawal ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
[openflow-discuss] How do you handle error messages? As Sync or Async ?
Hi all What is the expected/standard way to handle error messages to flow_mod requests? If they are treated as SYNC messages, then my application would have to wait for an ack. But if the switch has happily accepted the flow_mod, it does not send back anything - causing my app to hang forever. If they are treated as ASYNC messages, then my application fires off a flow_mod and hopes all's well and goes about doing other things. Sometime later an async error message might be received. Now my app's in trouble since I have already done things I shouldn't have and rolling back can be messy. One workaround to this might be: Send a flow_mod message. Set socket.timeout for a second maybe and if nothing arrived yet, then we can safely assume all's well. But this seems to be a very bad hack since the app has to wait unnecessarily even if things have gone well. Any other suggestions ? regards Gopal Agrawal ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
Re: [openflow-discuss] How do you handle error messages? As Sync or Async ?
Hi, The choice is yours. To do a synchronous call, send the flow_mod followed up a barrier_request. You will get the barrier_reply back. To do asynchronous calls, just send the flow_mod and wait for error messages. The error messages should carry the same xid (transaction id) as the flow_mod and the flow_mod generated the error. You do not need to tweak TCP options for this. It is usu. done in an async manner. If you are using a controller like NOX, then this should not really be of much concern. Are you whipping up a new controller? Regards KK On 20 May 2011 13:11, G A ga_a...@yahoo.com wrote: Hi all What is the expected/standard way to handle error messages to flow_mod requests? If they are treated as SYNC messages, then my application would have to wait for an ack. But if the switch has happily accepted the flow_mod, it does not send back anything - causing my app to hang forever. If they are treated as ASYNC messages, then my application fires off a flow_mod and hopes all's well and goes about doing other things. Sometime later an async error message might be received. Now my app's in trouble since I have already done things I shouldn't have and rolling back can be messy. One workaround to this might be: Send a flow_mod message. Set socket.timeout for a second maybe and if nothing arrived yet, then we can safely assume all's well. But this seems to be a very bad hack since the app has to wait unnecessarily even if things have gone well. Any other suggestions ? regards Gopal Agrawal ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
