Hi Jose, This sounds fairly serious and I don't know that I've seen this before.
1) What version of the flowvisor are you running? 2) Can you paste the exact error message from the logs? There should be in fact two stack traces: the one you're describing is the flowvisor's (failed) attempt to recover from the first error... it's really the first error that's most important. 3) Would it be possible to get a tcpdump of the control traffic (as described in the BUGS file)? Probably best to send this to me directly instead of to the list. Thanks in advance, - Rob . PS I'm not sure if I said so explicitly, but I have already committed your patch into the master branch -- thanks! On Wed, Jun 15, 2011 at 2:15 AM, Jose Francisco Mingorance-Puga <[email protected]> wrote: > Dear Rob, all, > > Assume this scenario. I am running FlowVisor, a controller on top of it, and > a switch below. > I fix a flow entry in the switch to send all packets matching a particular > flow to the controller. > Whenever any of those packets (non-openflow packets) are forwarded to the > controller (i.e. in practice FlowVisor) FlowVisor crashes. > > The error message is the cannot-bind-IP-because-already-in-use error that > made FlowVisor crash already in the past. > > Now I am wondering, is FlowVisor willing to take care of forwarding data > packets (i.e. non-openflow packets) from the switch to the controller? I am > referring to the case in which the controller set that rule in the switch. I > guess this should be possible somehow, if FlowVisor keeps track of which > controller asks which switch to forward data packets to the controller. If > no, this his a considerable drawback of FlowVisor. One dirty solution could > be to ask the switch to forward the packets through a different route, but I > don't consider it feasible in all scenarios. > > My questions are: > > - Do you know what should be the behavior of FlowVisor according the current > implementation? > - Have you ever found this problem? If so, did you find a workaround? > > In the meantime I will navigate into the source code to try to fix this, but > if any of you know a workaround would be really useful. > > > -- > Jose Francisco Mingorance-Puga > > ETH Zürich - Swiss Federal Institute of Technology Zurich > Computer Engeenering and Networks Laboratory > Communication Systems Group > > ETZ G 94 Gloriastrasse 35 > 8092 Zürich Switzerland > Phone: +41 44 632 70 52 > Skype name: jfmingorance > [email protected] > > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
