Hi Guanyao, I do not understand
"I think to guarantee flow_mod be set up for every switch, it is better to install in the initial order, that means, the first switch" In that case, the second packet-in will still occur. Wouldn't it? Imagine route A-B-C, and we send the flow_mod to A first. Then B will/might see the packet-in. My suggestion for the guarantee is to send to B and C with a barrier function it. Once both barrier function returns, we install A. That way, we are sure B and C has the entries before sending the flow_mod to A. Hope I am clear. Regards KK On 8 February 2010 19:39, Guanyao Huang <gyhu...@ucdavis.edu> wrote: > I heard this from my supervisor. I also think this is not resolved, > because it seems hard to resolve this. > I think to guarantee flow_mod be set up for every switch, it is better > to install in the initial order, that means, the first switch > installed first, because the packet will hit in this order. > I think this is unresolved, because I occasionally saw this happens. I > guess the only thing we can do is to handle new flow_in event. > > On Mon, Feb 8, 2010 at 7:10 PM, kk yap <yap...@stanford.edu> wrote: >> Hi Guanyao, >> >> From what I know this is not resolved. Do you recall where you heard >> that this is resolved in NOX 0.5? >> >> I put in a component in NOX 0.6 (not available publicly) to install >> the route/tree in reverse order, i.e., destination first. This is not >> foolproof either, since there is no guarantees on the flow_mod will >> reach the switch in that order. Just does better than the current >> order of installation. >> >> There exists a solution that totally removes the problem, but it adds >> an RTT delay. Basically you can (in theory) do a barrier function for >> each flow_mod and wait for all the replies before putting the flow_mod >> to the source switch. >> >> Regards >> KK >> >> On 8 February 2010 14:33, Guanyao Huang <gyhu...@ucdavis.edu> wrote: >>> Hi >>> Sorry to bother others. >>> In order to establish packet forwarding between switches, the rule >>> should be sent to switch before the first packet is sent back. The >>> race condition is the packet is sent back and even forwarded by the >>> first switch, but it doesnt find a rule in the second switch although >>> openflow command is already sent. I was told that conditions like this >>> were resolved after nox 0.5. My version is 0.5.0-full-beta, but I >>> still find this happens occasionally. Is there any other requirement >>> on the version? Also, how did you gaurrantee these conditions are >>> resolved. Did you try to control the delay of the packets on wire? >>> Thanks. >>> >>> _______________________________________________ >>> nox-dev mailing list >>> nox-dev@noxrepo.org >>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >> > _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
