Right. I understand. We want to flow_cmd B and C before sending back first packet. Thanks.
On Mon, Feb 8, 2010 at 8:19 PM, kk yap <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>> >>> >> > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
